I've learned that within a weak entity, each occurrence can't be uniquely identified using any available attributes within that entity. In other words, each occurrences can't be uniquely identified since there is no primary key.
All the textbooks and online materials give a solution to this by saying that we can uniquely identify each occurrence only through a relationship with an owner entity's primary key.
My question: Is it possible to just add a primary key to a weak entity?
then, a weak entity becomes a strong entity and we don't need to go through an owner's entity to uniquely identify each occurrences within a weak entity.
Related
First of all, I have read several similar questions with "technical" answers that look like C & P. What I need is a clear example. The normalization is 3NF.
In this project, in the administrative panel, you have to create cities and zones and each zone has to belong to a city. Also create hotels and assign them in the corresponding zone, and finally create aliases for each particular hotel, as people know the same hotel under different names. The tables hotels and hotels_alias are to fill an autocomplet input.
The price calculation is done according to the service (standard, private and VIP) depending on the zone and according to the number of passengers and the season, I still do not create the logic or tables to calculate the price per passenger and season. That is why they are not in the diagram below.
A good explanation I found is
What's the difference between identifying and non-identifying relationships?
However I have some doubts.
Example 1
hotels_alias can not exist without the table hotels that in turn can not exist without the zones table and this in turn does not exist without cities. Since a city is divided into many zones, hotels belong to these zones, zones that are part of a city, and hotel aliases belong to a hotel and can not exist if there is no hotel.
So far it is clear that cities are a strong or parent entity and zones, hotels and hotels_alias are child entities.
In the EER diagram you can see that it has an identifying relationship. The first question is: Is it correct that despite being child entities have their own ID? and that this ID is PK and NN and AI? In some examples, these child entities do not have their own ID, hence their PK is formed by two FKs from the related tables as in an N: N (zones_has_servicees) relationship.
If in fact child tables do not have to have their own ID because they must be able to identify themselves by their parent table, then how would you be able to update or delete an area, or a hotel or a hotel alias?
DELETE FROM zones WHERE name = 'name'
Is this correct? Should I create an index to the name column? What advantages, if any, would do with name colum instead of its own ID? Is it okay for a child table to have its own ID and create a composite PK with this ID and the ID of its parent table? Does this type of relationship have any function or is it only for engines like InnoDB ? to perform an ON DELETE CASCADE action?
What happens if I have two zones with the same name? for example: Hotel Zone, that both cities of Cancun and Tulum have that area. To make a DELETE would be ?:
DELETE FROM zones WHERE name = 'name' AND cities_id = ID
Understanding what a parent and a child entity is then why WordPress creates relationships like the one below where you can see that it uses a weak relationship with wp_postmeta and wp_posts. It is assumed that a wp_postmeta can not exist without a wp_posts, right? It does the same with comments and users.
WP EER
First, your example 1 is not an EER diagram (rather call it a table diagram). To be called an ER or EER diagram, you have to use a notation (like Chen's notation) that represents entity-relationship model concepts and distinguishes entity sets from relationships. In the ER model, both entity relations and relationship relations are implemented using tables, and neither map to FK constraints, which are just an integrity mechanism. Many people confuse the ER model for the old network data model.
Second, identifying relationships are used in conjunction with weak entity sets, in which the regular (parent) entity set's primary key forms part of the weak (child) entity set's primary key. When an entity set is identified by its own attributes, it's a regular entity set.
To delete a row from a weak entity relation, you would usually identify it by its primary key. Weak entity sets generally have a composite primary key, consisting of its parent's key and an additional weak key. The weak key need only be unique in conjunction with the parent key. For example, if zones were identified by cities_id and name, you could delete a zone by specifying those attributes:
DELETE FROM zones WHERE cities_id = 1 AND name = 'name';
The composite primary key should automatically be indexed and uniquely constrained by your DBMS if you declared it as the PK. The advantage of weak entity sets is that, in some cases, this method of identification is more natural than introducing a meaningless surrogate key.
It's not a good idea to have a table with a composite primary key consisting of a unique surrogate ID together with another attribute like its parent's ID. Besides the risk of unintended duplicate values if uniqueness isn't correctly enforced, it unnecessarily over-complicates what would otherwise be a straightforward table with a simple surrogate PK.
Your WordPress diagram doesn't illustrate weak entity sets or identifying relationships (and it's not an EER diagram, as mentioned before). The tables you mentioned each have their own surrogate keys. Note that there's no such thing as a weak relationship in the ER model.
Question
Is there a way to have a many-to-many relationship among 3 tables without the use of automatic incrementers (usually ID), or are ID's required for this?
Why I ask
I have 3 relative tables. Since one-to-one relationships seem to can't happen directly, I made a 4th to do one-to-many relationships to the other 3 tables. However, since there's still a primary key to each table, a value can only be used once in a table, which I don't want to happen.
What I have
Connectors has multiple Pockets which have multiple pins.
The 4th Table is ConnectorFullInfo
There is no requirement that a table have an "automatic incrementer" as a primary key.
But, a familiar pattern is to add a surrogate ID column as primary key on entity tables. The "ideal" primary key will be "anonymous" (carry no meaningful information), "unique" (no duplicate values), "simple" (single column, short simple native datatype), ...
There are a couple of schools of thought on whether it's a good idea to introduce a surrogate key. I will also note that there are those who have been later burned by the decision to use a natural key rather than a surrogate key. And there are those that haven't yet been burned by that decision.
In the case of "association" tables (tables introduced to resolve many-to-many relationships), the combination of the foreign keys can be used as the primary key. I often do this.
BUT, if the association table is itself turns out to be entity table, with it's own attributes, I will introduce a surrogate ID column. As an example, the association between person and club, a person can be a member of multiple clubs, and a club can have multiple members...
club +--< membership >--+ person
When we start adding attributes to membership (such as status, date_joined, office_held, etc... at that point membership isn't just an association table; it's turning into an entity. When I suspect that an association is actually an entity, so I'll add the surrogate ID column.
The other case where I will add a surrogate ID column to an association table is when we want to allow "duplicates", where we want to allow multiple associations. In that case, I will also introduce a surrogate ID column.
Yes you can but,
It is customary to represent a table row by a unique identifier which is the number, its becomes more efficient.
I came across a rather stumping question out of the blue. In SQL, would a primary key be considered an attribute to a particular entity? I've done some research and although it is a specific key to uniquely identify an attribute, would it also be included as an attribute to a particular entity? Part of me says yes and part of me says no since it is just a key that specifies an attribute. Any advice would be very useful.
If primary key is formed out of the attributes of the entity then its a part of the entity. In case of surrogate key its not a part of the entity but associated with it.
Hope I got the intent of your question.
I'm having trouble understanding the difference between partial keys/weak entities and foreign keys. I feel like an idiot for not being able to understand this stuff.
As I understand it:
Weak Entity: An entity that is dependent on another entity.
Partial Key: Specifies a key that that is only partially unique. Used for weak entities.
vs
Foreign Key: A key that is used to establish and enforce a relation between data in different tables.
These don't seem like they're the same thing, but I'm having trouble distinguishing their uses.
Take the [very] simple example:
We have employees specified by an empid. We also have children specified by name. A
child is uniquely specified by name when the parent (employee) is known.
Would the child entity be a weak identity where the partial key is the name (partially unique)? Or should I be using a foreign key because I'm trying to establish and enforce a relation between employee and child? I feel like I can justify both, but I also feel like I'm missing something here. Any insight is appreciated, and I apologize for the stupid questions.
The problem is not you, it is that the ancient textbook or whatever you are using is pure excreta, the "definitions" are not clear, and there have been standard definitions for Relational Databases in use for over 30 years, which are much more clear. The "definitions" you have posted are in fact quite the opposite, non-intuitive, and it is no surprise that people would get confused.
A Foreign Key in a child row, is the value that references its parent Primary Key (in the parent table).
Using IDEF1X terminology. An Identifying Relation is one in which the FK (the parent Pk in the child) is also used to form the child PK. It is unique in the parent, but not unique in the child, you need to add some column to make it unique. Hence the stupid term "Partial Key". Either it is a Key (unique) or it is not a Key; the concept of a "partial Key" is too stupid to contemplate.
In a properly Normalised and standard-compliant database, there will be very few Independent entities. All the rest will be Dependent on some Independent entity. Such entities are not "weak", except in the sense that they cannot exist without the entity that they are Dependent upon.
The use of Identifying Relations (as opposed to Non-identifying) is actually strong; it gives the Dependent ("weak") entities their Identifier. So silly terms like "weak" and "strong" should not be used in a science that demands precision.
Use standard terms.
But to answer your explicit question:
assuming that Employee is "strong" and has a Primary Key (EmployeeId)
then the "weak" EmployeeChild table would need a FK (EmployeeId) to identify the Employee
which would be the perfect first component of the EmployeeChild table, the adorable "partial key"
to which you might add ChildNo, in order to make an ordinary Relational Primary Key
but it is not really "partial" because it is the full Primary Key of the Parent.
Readers who are unfamiliar with the Standard for Modelling Relational Databases may find ▶IDEF1X Notation◀ useful.
A weak entity type is one whose primary key includes some attribute(s) that reference another entity. In other words a foreign key is a subset of the primary key. Therefore the entity cannot exist without its parent.
A partial key means just part of a key - some proper subset of the key attributes.
In your example if the primary key of a Child was (Empid, ChildName) with Empid as a foreign key referencing the Employee then Child is a weak entity. If Empid was not part of the primary key then Child would be a strong entity.
It's worth bearing in mind that the weak/strong distinction is purely an ER modelling concept. In relational database terms it doesn't make much difference. In particular the relational model doesn't make any distinction between primary keys and other candidate keys so for all practical purposes it doesn't make any difference to single out primary key attributes as being a "special" case when they reference other tables.
Suppose there is a relation between two entity Employees and Dependents. Employees is strong entity and Dependents is weak entity. Dependents have attributes Name, Age, Relation and Employees have attributes E_Id (primary key) and E_Name.
Then to satisfy relation we use foreign key E_Id in Dependents table which refers to the E_Id of Employees table.
But by using only foregin key we can't identify the tuples uniquely in Dependents table we require Name(partial key) attribute also to identify the tuples uniquely.
Example : suppose Dependents table has values in Name are Rahul, Akshat, Rahul then it will not unique and when it combine with E_Id then we can identify it uniquely.
E_Id with Name acts as primary key in Dependents table.
I have the below tables.
create table logical_id_seq (
logical_id int auto_increment,
primary key(logical_id)
);
create table mytable (
physical_id int auto_increment,
logical_id int not null references parent(logical_id),
data varchar(20),
primary key(physical_id)
);
The second table uses first table auto-generated value as its value. I am not sure how to model this in hibernate.
I read http://docs.jboss.org/hibernate/core/3.3/reference/en/html/mapping.html#mapping-declaration-onetoone, but I doesn't seem to understand.
It's actually hard to say, I don't know what you want to represent at the object level: is it a one-to-one foreign key association? a many-to-one association? is the association bi-directional? Using an ORM means thinking objects more than tables and it usually help to provide the object model.
I'll assume this is a one-to-one foreign key association. Here is what Java Persistence with Hibernate recommends:
7.1.2 One-to-one foreign key associations
Instead of sharing a primary key, two
rows can have a foreign key
relationship. One table has a foreign
key column that references the primary
key of the associated table. (The
source and target of this foreign key
constraint can even be the same table:
This is called a self-referencing
relationship.)
Let’s change the mapping from a User
to an Address. Instead of the shared
primary key, you now add a
SHIPPING_ADDRESS_ID column in the
USERS table:
<class name="User" table="USERS">
<many-to-one name="shippingAddress"
class="Address"
column="SHIPPING_ADDRESS_ID"
cascade="save-update"
unique="true"/>
</class>
The mapping element in XML for this
association is <many-to-one> — not
<one-to-one>, as you might have
expected. The reason is simple: You
don’t care what’s on the target side
of the association, so you can treat
it like a to-one association without
the many part. All you want is to
express “This entity has a property
that is a reference to an instance of
another entity” and use a foreign key
field to represent that relationship.
The database schema for this mapping
is shown in figure 7.3.
Figure 7.3 A one-to-one foreign
key association between USERS and
ADDRESS
An additional constraint enforces this
relationship as a real one to one. By
making the SHIPPING_ADDRESS_ID
column unique, you declare that a
particular address can be referenced
by at most one user, as a shipping
address. This isn’t as strong as the
guarantee from a shared primary key
association, which allows a particular
address to be referenced by at most
one user, period. With several foreign
key columns (let’s say you also have
unique HOME_ADDRESS_ID and
BILLING_ADDRESS_ID), you can
reference the same address target row
several times. But in any case, two
users can’t share the same address for
the same purpose.
Let’s make the association from User
to Address bidirectional.
Inverse property reference
The last foreign key association was
mapped from User to Address with
<many-to-one> and a unique
constraint to guarantee the desired
multiplicity. What mapping element can
you add on the Address side to make
this association bidirectional, so
that access from Address to User is
possible in the Java domain model?
In XML, you create a <one-to-one>
mapping with a property reference
attribute:
<one-to-one name="user"
class="User"
property-ref="shippingAddress"/>
You tell Hibernate that the user
property of the Address class is the
inverse of a property on the other
side of the association. You can now
call anAddress.getUser() to access
the user who’s shipping address you’ve
given. There is no additional column
or foreign key constraint; Hibernate
manages this pointer for you.
If what you have is actually a real many-to-one association, it should be pretty easy to adapt the above solution.