Defining one-to-many relationships

The most typical kind of cardinality in a relational database management system is one-
to-many, which is just as easily described as many-to-one. It just depends on which side
of the relationship you start at. In the example I showed earlier was this, perhaps the
archetypal one-to-many or many-to-one relationship. Customer and Order, one customer
can hae many orders. !eaning, one Customer row can be associated with multiple
Order rows but each Order row is only for one Customer.
"ow creating this relationship depends on us haing our primary keys defined first. If
you#re attempting to describe that we need to link from a row in one table to specific
rows in another table, we need a way to get to those specific rows and getting to a
specific row takes a primary key. $o going into this, we must hae our tables with our
columns and primary keys at least roughly planned out. "ext, implementing a new one-
to-many relationship re%uires a change to whateer table represents the many side of the
relationship.
$o, to relate Customer and Order tables, I don#t need to change anything about the
Customer table, that#s the one side. I need to add some extra information to the Order
table, and it#s the key to the Customer table. $o, Customer I&, and this again is called a
'oreign (ey. It represents a column in this Order table that is a key to a row in a
different table. These will specifically refer to one and only one row in the Customer
table.
)ou might find the Customer I& occurs more than once in order, but it#s always pointing
to only one row in the customer. *e always make the change to the many side of the
relationship because it#s the only way to do it. I can add one column with one alue to
eery Order row that will always point to a correct customer, but I cannot add one
column with one alue to the Customer row that could point to a ariety of different
orders. $o, I#m making a match between the columns in these different tables. "ow ery
often, we would use the same column name across both of those tables.
$o in this case, Customer I& and Customer, Customer I& and Order, but it doesn#t hae
to be the same because we are really making the match on the alues in these columns.
In some cases, you couldn#t use the same name because there#d be a conflict. +erhaps
both of these tables were defined with the primary key just called I&, or we couldn#t
reuse the I& column twice in the Order table. There would be a conflict there, it just
wouldn#t work. $o, we call it something else like Customer I&. It#s still a foreign key.
It just happens to hae a different column name between the different tables. ,nother
thing that you might see is a completely different name that attempts instead to describe
the relationship. $o, instead of using Customer I&, we might use something like +laced
-y as a column name. ,nd Order is +laced -y a particular Customer I&. It still refers to
a alue that#s in the I& column in the other table, it#s just using a different name. $o, the
name of the column doesn#t hae to match but the data type certainly should.
It doesn#t make sense to hae a primary key that#s an integer in one table, try and match
a column that#s described as character data in a different table. "ow it#s also ery
common to hae one table that takes part in multiple relationships. $o, a customer can
hae many orders. *e go to one-to-many relationship here, but we may decide that our
customers can hae multiple different addresses they may ship to, so we might add a
new table for address and hae another one-to-many relationship between customer and
address.
This is perfectly acceptable and ery common. ,nother option is that a table that is on
the many side of a one-to-many relationship could be on the one side of another. $o, for
example, Order might be the many side of the customer to order relationship but Order
itself could hae many order items, so it#s on the one side of that relationship. One
customer has many orders, one order can contain many order items. "ow as we start to
get a bit further, we#re going to want to start to diagram these a bit more specifically.
I#e shown the basics of entity relationship diagrams as they are ery simple to just get
started conceptually. -asically, boxes with lines between them. ,lthough as you start to
more formali.e the actual database diagram, you#ll see a different kind of layout emerge,
and there#s no fixed one standard. )ou#ll see different options used across different
database management systems and different charting applications. -ut they usually boil
down to this kind of idea. , box for each table with the name of the table at the top, then
we#d hae the column names.
)ou may or may not add a little extra to show what kind of data these are, character
data, dates, binary, integers, and so on. *hat is ery common is you would add a +( for
a primary key, and you would add an '( to denote a 'oreign (ey and then start adding
the relationship connector lines between them. This kind of diagram is ery, ery
common across all relational databases. It#s easy to see what tables exist, what columns,
what relationships exist between the tables.
"ow in most relational database management system administration software, there is
an option to generate these diagrams from an actual existing database in that serer, and
the relationships themseles will be shown with these connector lines. &ifferent
software tends to generate different looking lines. ,s I mentioned earlier, some will use
the Crow#s foot style to show the many part of a one-to-many relationship. $ome will
show the infinity symbol. There are other ways of doing this, but it#s usually not that
difficult to pick any one relationship and figure out which way it#s going.