Vous êtes sur la page 1sur 18


Introduction to database management system

1. What is data , relationship, constraints and schema?
a. Data is a collection of facts and also it is defined as binary computer
representation of logical entities.
b. Relationship is the association between the various data elements.
c. Constraints are predicates that define the correct database states.
d. Schema describes the organiation of data and relationship within the
!. What is a database?
a. Database is a collection of data designed to be used by different people is
called a database.
b. "nd the data is maintained with inter relationships with controlled
redundancy to serve one or more applications
#. What is database management system?
a. Database management system is a collection of programs that enables you
to store , modify and e$tract information from a database.
b. %he services provided by the database management system are
i. %ransaction management
1. a transaction is a se&uence of database operations that
represents a logical unit or words and that access the
database and transforms it form one state to another state
!. a transaction can update, delete, modify a set of records
ii. Concurrency control
1. it is the method of controlling the database manipulation
processes that are running simultaneously that access
shared data
iii. Recovery management
1. recovering the trasaction to its previous state if any failure
or abortion occurs while doing a transaction
iv. Security management
1. security management means protecting the data from
unauthoried access
v. 'anguage interface
1. the interface which is provided by the database
management system to do data manipulation without
worrying about the physical implementation
vi. storage management
1. the dbms allows us to store the data in the secondary
storage devices by interacting with the operating system
(. )$plain the types of database management system?
a. *ierarchical
i. %he hierarchical data model organies data in a tree structure.
%here is a hierarchy of parent and child data segments. +n this type
of structure .
ii. %his model organies the data elements as tabular rows one for
each instance of an entity.
iii. "dvantages, simplicity, Data security, Data integrity.
iv. Disadvantage, +mplementation comple$ity, database management
problems, programming comple$ity
b. -etwor. /odel
i. %he networ. model handles the many to many relationships. +t
allows records to have more than one parent. +n this a set is made
of at least two types of records owner record, and member record
c. Relational /odel
i. " database based on the relational model developed by ).0. Codd.
" relational database allows the definition of data structures,
storage and retrieval operations and integrity constraints.
ii. %he data and relations between them are organied in tables.
iii. " table is a collection of records and each record in a table
contains the same fields.
d. 1b2ect oriented /odel
i. 1b2ect D3/Ss add database functionality to ob2ect programming
ii. 1b2ect D3/Ss e$tend the semantics of the C44, Smalltal. and
5ava ob2ect programming languages to provide full6featured
database programming capability
iii. *ere entity is represented as a class . a class represents both ob2ect
attributes as well as their behaviors of the entity
iv. %his model is well suited for multimedia applications.
e. 1b2ect relational model
i. %his model combines the features of both ob2ect oriented and
relational model ma.ing it more powerful yet to manage the data
elements in the database.
Introduction to relational database management systems
1. )$plain the C1DD7s Rules?
a. C1DD defines 1! rules to &ualify a database as a
relational database
ii. +nformation rule
1. "ll information in the database is to be represented in one
and only one way, namely by values in column positions
within rows of tables.
iii. guaranteed access rule,
1. "ll data must be accessible.
!. this rule says that logically every record should be
accessable with a particular name of the containing table,
the name of the containing column and primary .ey value
of contatining row
iv. Systematic treatment of null values,
1. %he D3/S must allow each field to remain null 8or
!. +t should be independent of datatype.
v. "ctive online catalog based on the relational model,
1. %he system must support an online, inline, relational
catalog that is accessible to authoried users by means of
their regular &uery language.
vi. %he comprehensive data sublanguage rule,
1. %he system must support at least one relational language
!. *as a linear synta$
#. Can be used both interactively and within application
(. Supports data definition operations 8including view
definitions9, data manipulation operations 8update as well
as retrieval9, security and integrity constraints, and
transaction management operations 8begin, commit, and
vii. %he view updating rule,
1. "ll views that are theoretically updatable must be updatable
by the system.
viii. *igh6level insert, update, and delete,
1. %he system must support set6at6a6time insert, update, and
delete operators.
i$. :hysical data independence,
1. Changes to the physical level 8how the data is stored,
whether in arrays or lin.ed lists etc.9 must not re&uire a
change to an application based on the structure.
$. 'ogical data independence,
1. Changes to the logical level 8tables, columns, rows, and so
on9 must not re&uire a change to an application based on
the structure.
$i. +ntegrity independence,
1. +ntegrity constraints must be specified separately from
application programs and stored in the catalog.
$ii. Distribution independence,
1. he distribution of portions of the database to various
locations should be invisible to users of the database.
!. when a distributed version of the D3/S is first introduced;
#. when e$isting distributed data are redistributed around the
$iii. %he nonsubversion rule,
1. +f the system provides a low6level 8record6at6a6time9
interface, then that interface cannot be used to subvert the
Normal Forms
First Normal Form
A table is in first normal form (1NF) if there are no repeating groups.
" repeating group is a set of logically related fields or values that occur multiple times in
one record.
A Practical Approach
%he sample tables below do not comply with first normal form. 'oo. for fields that
contain too much data and repeating group of fields.
" table with fields containing too much data.
EmployeeID Name Project Time
)-16!> Sean 1?3rien #@6(A!6%#, #@6(AB6%#, #!6!((6%# @.!A, @.(@, @.#@
)-16## "my Cuya #@6(A!6%#, #@6#D!6%C, #!6!((6%# @.@A, @.#A, @.>@
)-16#A Steven 3aranco #@6(A!6%#, #16!#D6%C @.1A, @.D@
)-16#> )liabeth Roslyn #A61A!6%C @.E@
)-16#D Carol Schaaf #>6!B!6%C @.BA
)-16(@ "le$andra Wing #16!#D6%C, #16!(16%C @.!@, @.B@
%he e$ample above is also related to another design issue, namely, that each field should
hold the smallest meaningful value and that there should not be multiple values in a
single field.
Why is this table design a problem?
%here would be no way to sort by last names nor to .now which allocation of time
belonged to which pro2ect.
" table with repeating groups of fields.
EmpID Last Name First Name Project1 Time1 Project Time Project! Time!
)-16!> 1?3rien Sean #@6(A!6%# @.!A #@6(AB6%# @.(@ #!6!((6%# @.#@
)-16## Cuya "my #@6(A!6%# @.@A #@6#D!6%C @.#A #!6!((6%# @.>@
)-16#A 3aranco Steven #@6(A!6%# @.1A #16!#D6%C @.D@
)-16#> Roslyn )liabeth #A61A!6%C @.E@
)-16#D Schaaf Carol #>6!B!6%C @.BA
)-16(@ Wing "le$andra #16!#D6%C @.!@ #16!(16%C @.B@
So why is this one a problem?
+f an employee was assigned to a fourth pro2ect, you would have to add two new fields to
the table. "lso, it would be very difficult to total the amount of time devoted to a
particular pro2ect.
%he design problems addressed are very common6particularly among new designers who
are accustomed to trac.ing data in a spreadsheet. 1ften, when building a spreadsheet, we
arrange the data horiontally, laying it out across the spreadsheet. When designing tables,
we have to thin. more vertically. Similar data belongs in the same column or field with a
single value in each row.
Designing to meet first normal form
-ow we will ta.e the table you saw above and redesign it so it will comply with first
normal form.
Loo" at t#e repeating groups o$ data% Identi$y tables and $ields t#at &ill #old t#is
data &it#out t#e repeating groups% %hin. vertically and remember that similar data
belongs in the same field.
Enter t#e sample data $rom t#e table to ma"e sure you don't #a(e repeating groups%
I$ necessary) include $oreign "ey $ield*s+ to connect t#e tables%
EmployeeID Last Name First Name
)-16!> 1?3rien Sean
)-16## Cuya "my
)-16#A 3aranco Steven
)-16#> Roslyn )liabeth
)-16#D Schaaf Carol
)-16(@ Wing "le$andra
ProjectNum EmployeeID Time
#@6#!D6%C )-16## @.#A
#@6(A!6%# )-16!> @.!A
#@6(A!6%# )-16## @.@A
#@6(A!6%# )-16#A @.1A
#16!#D6%C )-16#A @.D@
#@6(AB6%# )-16!> @.(@
#16!#D6%C )-16(@ @.!@
#16!(16%C )-16(@ @.B@
#!6!((6%# )-16## @.>@
#A61A!6%C )-16#> @.E@
#>6!B!6%C )-16#D @.BA
Mar" t#e primary "ey $ield*s+ and $oreign "eys in eac# table% Shown below with F
indicating the :rimary Gey.
, EmployeeID Last Name First Name
)-16!> 1?3rien Sean
)-16## Cuya "my
)-16#A 3aranco Steven
)-16#> Roslyn )liabeth
)-16#D Schaaf Carol
)-16(@ Wing "le$andra
, ProjectNum , EmployeeID Time
#@6#!D6%C )-16## @.#A
#@6(A!6%# )-16!> @.!A
#@6(A!6%# )-16## @.@A
#@6(A!6%# )-16#A @.1A
#16!#D6%C )-16#A @.D@
#@6(AB6%# )-16!> @.(@
#16!#D6%C )-16(@ @.!@
#16!(16%C )-16(@ @.B@
#!6!((6%# )-16## @.>@
#A61A!6%C )-16#> @.E@
#>6!B!6%C )-16#D @.BA
+f an employee was assigned to an additional pro2ect, it would involve merely adding a
new record. "lso, it would be much easier to search for a particular pro2ect number as
they are all held in a single column.
Introducing Functional Dependency
3efore we go any further, there?s a new concept you need to be aware of and that?s
functional dependency. " functional dependency is a relationship between fields so that
the value in 0ield " determines the value in 0ield 3, and there can be only one value in
0ield 3. +n that case, 0ield 3 is functionally dependent on 0ield ". Consider the
following sample table,
-irport .ity
-ational Washington, DC
50G -ew <or.
'aCuardia -ew <or.
'ogan 3oston
Dulles Washington, DC
)ach airport name is uni&ue and each airport can be in only one city. %herefore, City is
functionally dependent on "irport. %he value in the "irport field determines what the
value will be in the City field 8ma.ing "irport the determinant field9 and there can be
only one value in the City field. %his does not need to wor. in the reverse. "s shown in
the table, a city can have more than one airport, so "irport is not functionally dependent
on City; the value in City does not necessarily determine what the value in "irport will
A table is in first normal form and each non-key field is functionally dependent on the
entire primary key.
'oo. for values that occur multiple times in a non6.ey field. %his tells you that you have
too many fields in a single table.
A Practical Approach
+n the e$ample below, see all the repeating values in the name and :ro2ect%itle fields.
%his is an inefficient way to store and maintain data. +n a well6designed database, the
only data that is duplicated is in .ey fields used to connect tables. %he presumption is that
the data in .ey fields will rarely change 8so it?s 1G if it?s repeated9 while the data in non6
.ey fields may change fre&uently 8so it?s not 1G to repeat it9.
" table with a multi6field primary .ey and repeating data in non6.ey fields
,EmployeeID LastName FirstName ,ProjectNumber ProjectTitle
)-16!> 1?3rien Sean #@6(A!6%# S%"R manual
)-16!> 1?3rien Sean #@6(AB6%# +S1 procedures
)-16!> 1?3rien Sean #161!(6%# )mployee handboo.
)-16## Cuya "my #@6(A!6%# S%"R manual
)-16## Cuya "my #@6(D!6%C Web Site
)-16## Cuya "my #16!(16%C -ew catalog
)-16#A 3aranco Steven #@6(A!6%# S%"R manual
)-16#A 3aranco Steven #16!#D6%C S%"R prototype
)-16#> Roslyn )liabeth #A61A!6%C S%"R pricing
)-16#D Schaaf Carol #>6!B!6%C 1rder system
)-16(@ Wing "le$andra #16!#D6%C S%"R prototype
)-16(@ Wing "le$andra #16!(16%C -ew catalog
+f a :ro2ect%itle changed, you would have to edit it in several records. "nd what would
happen in this table if the )mployee+D was part of the primary .ey and you wanted to
add a new :ro2ect-um and :ro2ect%itle even though no employees had yet been
%he primary .ey cannot contain a null value so you couldn?t add the new pro2ect.
"dditionally, if a pro2ect ended and you wanted to delete it, you would have to delete the
individual values because, if you deleted the records containing the titles and an
employee was assigned to only that pro2ect, you would also delete that employee?s record
6 something that you may not want to do.
+n the above e$ample, the asteris.s indicate the fields that ma.e up the primary .ey of
this table as it now stands. " multi6field primary .ey is necessary because neither the
)mployee+D nor the :ro2ect-um fields contain uni&ue values.
%he reason there are repeated values in 'ast-ame, 0irst-ame, and :ro2ect%itle is that
these fields are dependent on only part of the primary .ey. %he value in )mployee+D
determines what the value in 'ast-ame will be but the value in :ro2ect-um has nothing
to do with it. Similarly, the value in :ro2ect-um determines the value in :ro2ect%itle but
)mployee+D does not. %hese non6.ey fields relate to only part of the primary .ey. hey
are not functionally dependent on the entire primary key.
%he solution to this lies in brea.ing the table into smaller tables that do meet second
normal form. <ou will find that more tables is the solution to most problems encountered
during data normalisation.
Complying with second normal form
-ow we?ll ta.e the table above and design new tables that will eliminate the repeated data
in the non6.ey fields.
1. %o decide what fields belong together in a table, thin. about which field
determines the values in other fields. .reate a table $or t#ose $ields and enter
t#e sample data%
!. %hin. about what the primary .ey for each table would be and about the
relationship between the tables. I$ necessary) add $oreign "eys or a junction
#. Mar" t#e primary "ey $or eac# table and ma"e sure t#at you don't #a(e
repeating data in non/"ey $ields%
,EmployeeID Last Name First Name
)-16!> 1?3rien Sean
)-16## Cuya "my
)-16#A 3aranco Steven
)-16#> Roslyn )liabeth
)-16#D Schaaf Carol
)-16(@ Wing "le$andra
,EmployeeID ,ProjectNum
)-16!> #@6(A!6%#
)-16!> #@6(AB6%#
)-16!> #161!(6%#
)-16## #@6#!D6%C
)-16## #@6(A!6%#
)-16## #!6!((6%#
)-16#A #@6(A!6%#
)-16#A #16!#D6%C
)-16#> #A61A!6%C
)-16#D #>6!B!6%C
)-16(@ #16!#D6%C
)-16(@ #16!(16%C
,ProjectNum ProjectTitle
#@6(A!6%# S%"R manual
#@6(AB6%# +S1 procedures
#@6(D!6%C Web site
#161!(6%# )mployee handboo.
#16!#D6%C S%"R prototype
#16!#D6%C -ew catalog
#A61A!6%C S%"R pricing
#>6!B!6%C 1rder system
)$amine the tables to ma.e sure there are no repeating values in non6.ey fields and that
the value in each non6.ey field is determined by the value8s9 in the .ey field8s9. %his
removes the modification anomaly of having the repeated values.
A table is in second normal form (!NF) and there are no transiti"e dependencies.
" transiti(e dependency is a type of functional dependency in which the value in a non6
.ey field is determined by the value in another non6.ey field and that field is not a
candidate .ey.
A Practical Approach
"gain, loo. for repeated values in a non6.ey field as in the following e$ample.
" table with a single field primary .ey and repeating values in non6.ey fields.
,ProjectNum ProjectTitle ProjectMgr P#one
#@6(A!6%# S%"R manual Carrison !BA>
#@6(AB6%# +S1 procedures 5acanda !EA(
#@6(D!6%C Web site 0riedman !D(>
#161!(6%# )mployee handboo. 5ones #1@!
#16!#D6%C S%"R prototype Carrison !BA>
#16!(16%C -ew catalog 5ones #1@!
#A61A!6%C S%"R pricing Hance #@!!
#>6!B!6%C 1rder system 5acanda !EA(
%he phone number is repeated each time a manager name is repeated. %his is because the
phone number is only a second cousin to the pro2ect number. +t?s dependent on the
manager, which is dependent on the pro2ect number 8a transitive dependency9.
%he :ro2ect/gr field is not a candidate .ey because the same person manages more than
one pro2ect. "gain, the solution is to remove the field with repeating data to a separate
Complying with third normal form
"s you?ve probably come to e$pect by now, you?ll ta.e the above table and create new
tables to fi$ the problem.
1. T#in" about &#ic# $ields belong toget#er and create ne& tables to #old t#em%
!. Enter t#e sample data and c#ec" $or unnecessarily *not part o$ primary "ey+
repeated (alues%
#. Identi$y t#e primary "ey $or eac# table and) i$ necessary) add $oreign "eys%
,ProjectNum ProjectTitle ProjectMgr
#@6(A!6%# S%"R manual Carrison
#@6(AB6%# +S1 procedures 5acanda
#@6(D!6%C Web site 0riedman
#161!(6%# )mployee handboo. 5ones
#16!#D6%C S%"R prototype Carrison
#16!(16%C -ew catalog 5ones
#A61A!6%C S%"R pricing Hance
#>6!B!6%C 1rder system 5acanda
,ProjectMgr P#one
0riedman !D(>
Carrison !BA>
5acanda !EA(
5ones #1@!
Hance #@!!
Re6e$amine your tables to ma.e sure there are no unnecessarily repeating values in non6
.ey fields and that the value in each non6.ey field is determined by the value8s9 in the
.ey field8s9.
Boyce-Codd Normal Form:
A table is in third normal form (#NF) and all determinants are candidate keys.
3oyce6Codd normal form 83C-09 can be thought of as a InewI third normal form. +t was
introduced to cover situations that the IoldI third normal form did not address. Geep in
mind the mean of a determinant 8determines the value in another field9 and candidate
.eys 8&ualify for designation as primary .ey9. %his normal form applies to situations
where you have overlapping candidate .eys.
+f a table has no non6.ey fields, it is automatically in 3C-0.
A Practical Approach
'oo. for potential problems in updating e$isting data 8modification anomaly9 and in
entering new data 8insertion anomaly9.
+magine that you were designing a table for a college to hold information about courses,
students, and teaching assistants. <ou have the following business rules.
)ach course can have many students.
)ach student can ta.e many courses.
)ach course can have multiple teaching assistants 8%"s9.
)ach %" is associated with only one course.
0or each course, each student has one %".
Some sample data,
.ourseNum Student T-
)-C1@1 5ones Clar.
)-C1@1 Crayson Chen
)-C1@1 Samara Chen
/"%#A@ Crayson :owers
/"%#A@ 5ones 1?Shea
/"%#A@ 3erg :owers
%o uni&uely identify each record, you could choose Course-um 4 Student as a primary
.ey. %his would satisfy third normal form also because the combination of Course-um
and Student determines the value in %". "nother candidate .ey would be Student 4 %".
+n this case, you have overlapping candidate .eys 8Student is in both9. %he second choice,
however, would not comply with third normal form because the Course-um is not
determined by the combination of Student and %"; it only depends on the value in %"
8see the business rules9. %his is the situation that 3oyce6Codd normal form addresses; the
combination of Student 4 %" could not be considered to be a candidate .ey.
+f you wanted to assign a %" to a course before any students enrolled, you couldn?t
because Student is part of the primary .ey. "lso, if the name of a %" changed, you would
have to update it in multiple records.
+f you assume you have 2ust these fields, this data would be better stored in three tables,
one with Course-um and Student, another with Student and %", and a third with
Course-um and %".
,.ourseNum ,Student
)-C1@1 5ones
)-C1@1 Crayson
)-C1@1 Samara
/"%#A@ Crayson
/"%#A@ 5ones
/"%#A@ 3erg
,Student ,T-
5ones Clar.
Crayson Chen
Samara Chen
Crayson :owers
5ones 1?Shea
3erg :owers
,.ourseNum ,T-
)-C1@1 Clar.
)-C1@1 Chen
/"%#A@ 1?Shea
/"%#A@ :owers
"bove, showing tables that comply with 3C-0
Fourth Normal Form:
A table is in $oyce-%odd normal form ($%NF) and there are no multi-"alued
" multi-"alued dependency occurs when, for each value in field ", there is a set of values
for field 3 and a set of values for field C but fields 3 and C are not related.
A Practical Approach
'oo. for repeated or null values in non6.ey fields.
" multi6valued dependency occurs when the table contains fields that are not logically
related. "n often used e$ample is the following table,
,Mo(ie ,Star ,Producer
1nce Jpon a %ime 5ulie Carland "lfred 3rown
1nce Jpon a %ime /ic.ey Rooney "lfred 3rown
1nce Jpon a %ime 5ulie Carland /uriel *umphreys
1nce Jpon a %ime /ic.ey Rooney /uriel *umphreys
/oonlight *umphrey 3ogart "lfred 3rown
/oonlight 5ulie Carland "lfred 3rown
" movie can have more than one star and more than one producer. " star can be in more
than one movie. " producer can produce more than one movie. %he primary .ey would
have to include all three fields and so this table would be in 3C-0. 3ut you have
unnecessarily repeated values, with the data maintenance problems that causes, and you
would have trouble with deletion anomalies.
%he Star and the :roducer really aren?t logically related. %he /ovie determines the Star
and the /ovie determines the :roducer. %he answer is to have a separate table for each of
those logical relationships 6 one holding /ovie and Star and the other with /ovie and
:roducer, as shown below,
,Mo(ie ,Star
1nce Jpon a %ime 5ulie Carland
1nce Jpon a %ime /ic.ey Rooney
/oonlight *umphrey 3ogart
/oonlight 5ulie Carland
,Mo(ie ,Producer
1nce Jpon a %ime "lfred 3rown
1nce Jpon a %ime /uriel *umphreys
/oonlight "lfred 3rown
"bove, showing tables that comply with (-0
3elow is another e$ample of a common design error, and it?s easily spotted by all the
missing or blan. values.
Dept.ode ProjectNum ProjectMgrID E0uipment PropertyID
+S #>6!B!6%C )-161A CD6R1/ >AB
+S HC" des.top monitor #@A
"C #A61A!6%C )-161A
"C Dot6matri$ printer #AD
"C Calculator with tape !#E
%W #@6(A!6%# )-161@ (D> :C !BA
%W #@6(AB6%# )-161A
%W #161!(6%# )-161A 'aser printer 1@E
%W #16!#D6%C )-161A *and6held scanner (BE
R+ 0a$ machine BBA
/G 'aser printer DAD
/G "nswering machine 1DB
%W #16!(16%C )-161A Standard 1E!@@ bps modem #D>
S' (D> 'aptop :C BB!
S' )lectronic noteboo. (AD
"bove, a table with many null values 8note, it also does not comply with #-0 and 3C-09
+t?s the same problem here because not all of the data is logically related. "s usual, the
answer is more tables 6 one to hold the information on the e&uipment assigned to
departments 8with :roperty+D as the primary .ey9 and another with pro2ects and
departments. <ou?d have to .now the business rules to .now whether a pro2ect might
involve more than one department or manager and be able to figure out the primary .ey.
"ssuming a pro2ect can have only one manager and be associated with only one
department, the tables would be as follows.
,PropertyID E0uipment Dept.ode
>AB CD6R1/ +S
#@A HC" des.top monitor +S
#AD Dot6matri$ printer "C
!#E Calculator with tape "C
!BA (D> :C %W
1@E 'aser printer %W
(BE *and6held scanner %W
BBA 0a$ machine R+
DAD 'aser printer /G
1DB "nswering machine /G
#D> Standard 1E!@@ bps modem %W
BB! (D> 'aptop :C S'
(AD )lectronic noteboo. S'
,ProjectNum ProjectMgrID Dept.ode
#>6!B!6%C )-161A +S
#A61A!6%C )-161A "C
#@6(A!6%# )-161@ %W
#@6(AB6%# )-161A %W
#161!(6%# )-161A %W
#16!#D6%C )-161A %W
#16!(16%C )-161A %W
"bove, tables that eliminate the null values and comply with (-0
Fifth Normal Form:
A table is in fourth normal form (&NF) and there are no cyclic dependencies.
" cyclic dependency can occur only when you have a multi6field primary .ey consisting
of three or more fields. 0or e$ample, let?s say your primary .ey consists of fields ", 3,
and C. " cyclic dependency would arise if the values in those fields were related in pairs
of " and 3, 3 and C, and " and C.
0ifth normal form is also called pro2ection62oin normal form. " pro'ection is a new table
holding a subset of fields from an original table. When properly formed pro2ections are
2oined, they must result in the same set of data that was contained in the original table.
A Practical Approach
'oo. for the number of records that will have to be added or maintained
0ollowing is some sample data about buyers, the products they buy, and the companies
they buy from on behalf of /ega/all, a large department store.
,Buyer ,Product ,.ompany
Chris 2eans 'evi
Chris 2eans Wrangler
Chris shirts 'evi
'ori 2eans 'evi
"bove, a table with cyclic dependencies
%he primary .ey consists of all three fields. 1ne data maintenance problem that occurs is
that you need to add a record for every buyer who buys a product for every company that
ma.es that product or they can?t buy from them. %hat may not appear to be a big deal in
this sample of ! buyers, ! products, and ! companies 8! L ! L ! M D total records9. 3ut
what if you went to !@ buyers, A@ products, and 1@@ companies 8!@ L A@ L 1@@ M
1@@,@@@ potential records9? +t &uic.ly gets out of hand and becomes impossible to
<ou might be tempted to solve this by dividing this into the following two tables.
,Buyer ,Product
Chris 2eans
Chris shirts
'ori 2eans
,Product ,.ompany
2eans Wrangler
2eans 'evi
shirts 'evi
*owever, if you 2oined the two tables above on the :roduct field, it would produce a
record not part of the original data set 8it would say that 'ori buys 2eans from Wrangler9.
%his is where the pro2ection62oin concept comes in.
%he correct solution would be three tables,
,Buyer ,Product
Chris 2eans
Chris shirts
'ori 2eans
,Product ,.ompany
2eans Wrangler
2eans 'evi
shirts 'evi
,Buyer ,.ompany
Chris 'evi
Chris Wrangler
'ori 'evi
"bove, tables that comply with A-0