StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
11110385
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
2012-06-20T03:10:18.417
CreationDate
2012-06-19T22:26:23.030
FavoriteCount
0
LastActivityDate
2012-06-20T03:12:43.843
LastEditDate
2012-06-20T03:12:43.843
LastEditorUserId
1446794
OwnerUserId
1446794
ParentId
11108846
PostTypeId
2
Score
9
ViewCount
0
LastEditorDisplayName
text
Body
A child table (A.K.A. <a href="http://en.wikipedia.org/wiki/Weak_entity" rel="noreferrer">weak entity</a>) is a table whose primary key attributes depend on another table, thus the child table is identified or partially identified by rows in the table it depends on (parent). Rows in a child table cannot exist without a corresponding row in its parent table. To illustrate, let's take a simple and completely relevant example we are all familiar with: Parents and children in the context of family. We can model out this relationship with tables like so: <img src="https://i.stack.imgur.com/guJAB.jpg" alt="Parent to Child Identifying Relationship"> In the model above, each row in the <code>Parents</code> table is uniquely identified by an <code>SSN</code>. The <code>SSN</code> is an intrinsic and unique attribute to each parent, thus it is a standalone or "strong" entity because it does not rely on another table to define its identity. Children however, require a parent in order to exist (<code>Parent_SSN</code> must reference to an existing <code>SSN</code> in the <code>Parents</code> table). Notice the composite primary key (<code>Parent_SSN, Name</code>) in the <code>Children</code> table. This means that children are uniquely identified by the combination of <code>Parent_SSN</code> and <code>Name</code>. You cannot query for an individual child based only on the <code>Name</code> field because multiple parents may have children with the same name. Likewise, you cannot query for an individual child based only on the <code>Parent_SSN</code> field because one parent may have many children. Taking that into consideration, children are partially identified by their parent, hence identifying relationship. But can't children be uniquely identified by an SSN as well? Why yes, certainly. Let's go ahead and adjust our model to include that: <img src="https://i.stack.imgur.com/JUcIa.jpg" alt="Parent to Child Non-Identifying Relationship"> In this version of the model, notice we have introduced the <code>SSN</code> field for <code>Children</code>. The unique identity of children is now defined by their own intrinsic and unique <code>SSN</code>. Their identity no longer depends on the <code>Parents</code> table. Although the <code>Parent_SSN</code> field still references the <code>SSN</code> of the <code>Parents</code> table, it has no part in the unique identity of the child, thus parents have a non-identifying relationship to their children, and both tables can now be considered "strong" standalone entities. As an aside, this version of the model has a few advantages over the first: <ul> <li>One parent may now have two or more children with the same name, whereas the <a href="http://en.wikipedia.org/wiki/Entity_integrity" rel="noreferrer">entity integrity</a> constraint in the previous model would not allow for this.</li> <li>You can allow the <code>Parent_SSN</code> field to contain <code>NULL</code> to account for the event that you have data about the child, but do not know who his/her parent is.</li> </ul> In both of the above models, the <code>Parents</code> table is considered to be the parent table of the <code>Children</code> table. However, in non-identifying relationships like in the second model, <code>Parents</code> is only a parent table in the context of the foreign key <code>Parent_SSN</code> because <code>Parent_SSN</code> references/depends on <code>SSN</code> in the <code>Parents</code> table, but does not have any part in defining the actual identity of children. To illustrate why context is important when deciding which tables are parent/child tables, consider the following example involving a circular dependency: <img src="https://i.stack.imgur.com/4QAHu.jpg" alt="Employee Department Relationships"> In this example, employees and departments are uniquely identified by their own attributes and do not derive any part of their identity from other tables. Here, we have two non-identifying relationships: an employee works for a department (<code>DeptNo</code> in the <code>Employee</code> table), and a department is managed by an employee (<code>ManagerSSN</code> in the <code>Department</code> table). Which one is the parent table? ...Child table? It depends on context — which foreign key relationship are you talking about? The Department table would be considered the parent table in the context of <code>DeptNo</code> in the <code>Employee</code> table because <code>DeptNo</code> is referencing/dependent on the <code>Department</code> table. However, the Employee table would be considered the parent table in the context of <code>ManagerSSN</code> in the <code>Department</code> table because <code>ManagerSSN</code> is referencing/dependent on the <code>Employee</code> table.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhich is the child table in a Identifying or Non-Identifying Relationship?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USZane Bien
UserOwnerUserId
1. USZane Bien
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.