CEC005 Module 4 CANVAS Merged
CEC005 Module 4 CANVAS Merged
Topics
4.1 | Relational Database Modeling and Normalization
4.1 | Relational Database Modeling
Relational Database Modeling
▪ The earliest model was the hierarchical database model, resembling an upside-down
tree.
▪ Files are related in a parent-child manner, with each parent capable of relating to
more than one child, but each child only being related to one parent. Most of you will
be familiar with this kind of structure—it’s the way most file systems work. There is
usually a root, or top-level, directory that contains various other directories and files.
Each subdirectory can then contain more files and directories, and so on. Each file
or directory can only exist in one directory itself—it only has one parent. As you can
see in the image below A1 is the root directory, and its children are B1 and B2. B1 is
a parent to C1, C2, and C3, which in turn has children of its own.
This model, although being a vast improvement on dealing with unrelated files, has
some serious disadvantages. It represents one-to-many relationships well (one parent
has many children; for example, one company branch has many employees), but it has
problems with many-to-many relationships. Relationships such as that between a
product file and an orders file are difficult to implement in a hierarchical model.
Specifically, an order can contain many products, and a product can appear in many
orders.
Also, the hierarchical model is not flexible because adding new relationships can result
in wholesale changes to the existing structure, which in turn means all existing
applications need to change as well. This is not fun when someone has forgotten a
table and wants it added to the system shortly before the project is due to launch! And
developing the applications is complex because the programmer needs to know the
data structure well in order to traverse the model to access the needed data. As you’ve
seen in the earlier chapters, when accessing data from two related tables, you only
need to know the fields you require from those two tables. In the hierarchical model,
you’d need to know the entire chain between the two. For example, to relate data
from A1 and D4, you’d need to take the route: A1, B1, C3 and D4.
Understanding the Network Database Model
The network database model was a progression from the hierarchical database
model and was designed to solve some of that model's problems, specifically the lack of
flexibility. Instead of only allowing each child to have one parent, this model allows each
child to have multiple parents (it calls the children members and the parents owners). It
addresses the need to model more complex relationships such as the orders/parts
many-to-many relationship mentioned in the hierarchical article. As you can see in the
figure below, A1 has two members, B1 and B2. B1. is the owner of C1, C2, C3 and C4.
However, in this model, C4 has two owners, B1 and B2.
Of course, this model has its problems, or everyone would still be using it. It is more difficult to
implement and maintain, and, although more flexible than the hierarchical model, it still has
flexibility problems, Not all relations can be satisfied by assigning another owner, and the
programmer still has to understand the data structure well in order to make the model efficient.
• Data are the values kept in the database. On their own, the data means very
little. CA 684-213 is an example of data in a DMV (Division of Motor Vehicles)
database.
• Information is processed data. For example, CA 684-213 is the car registration
number of a car belonging to Lyndon Manson, in a DMV database.
• A database is a collection of tables, also called entities.
• Each table is made up of records (the horizontal rows in the table, also
called tuples). Each record should be unique, and can be stored in any order in the
table.
• Each record is made up of fields (which are the vertical columns of the table, also
called attributes). Basically, a record is one fact (for example, one customer or one
sale).
• These fields can be of various types. Generally, types fall into three kinds: character,
numeric, and date. For example, a customer name is a character field, a customer's
birthday is a date field, and a customer's number of children is a numeric field.
• The range of allowed values for a field is called the domain (also called a field
specification). For example, a credit card field may be limited to only the
values Mastercard , Visa and Amex .
• A field is said to contain a null value when it contains nothing at all. Null fields can
create complexities in calculations and have consequences for data accuracy. For
this reason, many fields are specifically set not to contain null values.
• A key accesses specific records in a table.
• An index is a mechanism to improve the performance of a database. Indexes are
often confused with keys. Indexes are, strictly speaking, part of the physical
structure, and keys are part of the logical structure. You'll often see the terms used
interchangeably, however, including throughout this Knowledge Base.
• A view is a virtual table made up of a subset of the actual tables.
• A one-to-one (1:1) relationship is where for each instance of the first table in a
relationship, only one instance of the second table exists, An example of this would
be a case where a chain of stores carries a vending machine. Each vending
machine can only be in one store, and each store carries only one vending machine.
• A one-to-many (1:N) relationship is where for each instance of the first table in a
relationship, many instances of the second table exist. This is a common kind of
relationship. An example is the relationship between a sculptor and their sculptures.
Each sculptor may have created many sculptures, but each sculpture has been created
by only one sculptor.
• A many-to-many (M:N) relationship occurs where, for each instance of the first table,
there are many instances of the second table, and for each instance of the second table,
there are many instances of the first. For example, a student can have many lecturers,
and a lecturer can have many students.
• A mandatory relationship exists where for each instance of the first table in a
relationship, one or more instances of the second must exist. For example, for a music
group to exist, there must exist at least one musician in that group.
• An optional relationship is where for each instance of the first table in a relationship,
there may exist instances of the second. For example, if an author can be listed in the
database without having written a book (in other words, a prospective author), that
relationship is optional. The reverse isn't necessarily true though. For example, for a
book to be listed, it must have an author.
• Data integrity refers to the condition where data is accurate, valid, and consistent. An
example of poor integrity would be if a customer telephone number is stored differently in
two different locations. Another is where a course record contains a reference to a
lecturer who is no longer present at the school. Database normalization is a technique
that assists you to minimize the risk of these sorts of problems.
At first glance, there are two possible candidate keys for this table.
Either CustomerCode or a combination of FirstName, Surname and TelNo would
suffice. It is always better to choose the candidate key with the least number of fields for
the primary key, so you would choose CustomerCode in this example (note that it is a
surrogate key). Upon reflection, there is also the possibility of the second combination
not being unique. The combination of FirstName, Surname and TelNo could in theory
be duplicated, such as where a father has a son of the same name who is contactable
at the same telephone number. This system would have to expressly exclude this
possibility for these three fields to be considered for the status of primary key.
There may be many Ariane Edisons, but you avoid confusion by assigning each a
unique number. Once a primary key has been created, the remaining candidates are
labeled as alternate keys.
Lecturer table
1 Anne Cohen
2 Leonard Clark
3 Vusi Cave
Course table
Introduction to Programming 1
Information Systems 2
Systems Software 3
Referential integrity exists here, as all the lecturers in the course table exist in the lecturer table.
However, let's assume Anne Cohen leaves the institution, and you remove her from the lecturer
table. In a situation where referential integrity is not enforced, she would be removed from the
lecturer table, but not from the course table, as shown below:
Lecturer table
2 Leonard Clark
3 Vusi Cave
Course table
Introduction to Programming 1
Information Systems 2
Systems Software 3
Now, when you look up who lectures Introduction to Programming, you are sent to a
non-existent record. This is called poor data integrity.
Foreign keys also allow cascading deletes and updates. For example, if Anne Cohen
leaves, taking the Introduction to Programming Course with her, all trace of her can be
removed from both the lecturer and course table using one statement. The
delete cascades through the relevant tables, removing all relevant records.
Foreign keys can also contain null values, indicating that no relationship exists.
Student View
First name
Surname
Grade
Student Table
Student_id
First name
Surname
Grade
Address
Telephone
This view could be used to allow other students to see their fellow student's marks but
not allow them access to personal information.
Alternatively, a view could be a combination of a number of tables, such as the view
below:
Student View
First name
Surname
Grade
Student Table
Student_id
First name
Surname
Address
Telephone
Course Table
Course_id
Course description
Grade Table
Student_id
Course_id
Grade
Views are also useful for security. In larger organizations, where many developers may be
working on a project, views allow developers to access only the data they need. What they don't
need, even if it is in the same table, is hidden from them, safe from being seen or manipulated.
It also allows queries to be simplified for developers. For example, without the view, a developer
would have to retrieve the fields in the view with the following sort of query
With this view, a developer could do the same with the following:
Much simpler for a junior developer who hasn't yet learned to do joins, and it's just less
hassle for a senior developer too!
Database Design
▪ Phase 1: Analysis
▪ Phase 2: Conceptual Design
▪ Phase 3: Logical and Physical Design
▪ Phase 4: Implementation
▪ Phase 5: Testing
▪ Phase 6: Operation
▪ Phase 7: Maintenance
4.2 | Database Normalization
Database Normalization
Normalization is a technique that can help you avoid data anomalies and other
problems with managing your data.
It consists of transforming a table through various stages: 1st normal form, 2nd normal
form, 3rd normal form, and beyond.
It aims to:
Let's begin by creating a sample set of data. You'll walk through the process of
normalization first without worrying about the theory, to get an understanding of the
reasons you'd want to normalize. Once you've done that, we'll introduce the theory and
the various stages of normalization, which will make the whole process described below
much simpler the next time you do it.
Imagine you are working on a system that records plants placed in certain locations,
and the soil descriptions associated with them.
The location:
• Location Code: 11
• Location name: Kirstenbosch Gardens
The location:
• Location Code: 12
• Location name: Karbonkelberg Mountains
Tables in a relational database are in a grid, or table format (MariaDB, like most modern
DBMSs is a relational database), so let's rearrange this data in the form of a tabular
report:
Kirstenbosch
11 431 Leaucadendron A Sandstone
Gardens
Karbonkelberg
12 431 Leucadendron A Sandstone
Mountains
How are you to enter this data into a table in the database? You could try to copy the
layout you see above, resulting in a table something like the below. The null fields
reflect the fields where no data was entered.
Trying to create a table with plant data
Kirstenbosch
11 431 Leucadendron A Sandstone
Gardens
Karbonkelberg
12 431 Leucadendron A Sandstone
Mountains
This table is not much use, though. The first three rows are actually a group, all
belonging to the same location. If you take the third row by itself, the data is incomplete,
as you cannot tell the location the Erica is to be found. Also, with the table as it stands,
you cannot use the location code, or any other fields, as a primary key (remember, a
primary key is a field, or list of fields, that uniquely identify one record). There is not
much use in having a table if you can't uniquely identify each record in it.
So, the solution is to make sure each table row can stand alone, and is not part of a
group, or set. To achieve this, remove the groups, or sets of data, and make each row a
complete record in its own right, which results in the table below.
Kirstenbosch
11 431 Leucadendron A Sandstone
Gardens
Kirstenbosch
11 446 Protea B Sandstone/limestone
Gardens
Kirstenbosch
11 482 Erica C Limestone
Gardens
Karbonkelberg
12 431 Leucadendron A Sandstone
Mountains
Karbonkelberg
12 449 Restio B Sandstone/limestone
Mountains
Notice that the location code cannot be a primary key on its own. It does not uniquely
identify a row of data. So, the primary key must be a combination of location
code and plant code. Together these two fields uniquely identify a row of data. Think
about it. You would never add the same plant type more than once to a particular
location. Once you have the fact that it occurs in that location, that's enough. If you want
to record quantities of plants at a location - for this example, you're just interested in the
spread of plants - you don't need to add an entire new record for each plant; rather, just
add a quantity field. If for some reason you would be adding more than one instance of
a plant/location combination, you'd need to add something else to the key to make it
unique.
So, now the data can go in table format, but there are still problems with it. The table
stores the information that code 11 refers to Kirstenbosch Gardens three times! Besides
the waste of space, there is another serious problem. Look carefully at the data below.
Data anomaly
Kirstenbosch
11 431 Leucadendron A Sandstone
Gardens
Kirstenbosh
11 446 Protea B Sandstone/limestone
Gardens
Kirstenbosch
11 482 Erica C Limestone
Gardens
Karbonkelberg
12 431 Leucadendron A Sandstone
Mountains
Karbonkelberg
12 449 Restio B Sandstone/limestone
Mountains
Did you notice anything strange? Congratulations if you did! Kirstenbosch is misspelled
in the second record. Now imagine trying to spot this error in a table with thousands of
records! By using the structure in the table above, the chances of data anomalies
increases dramatically.
The solution is simple. You remove the duplication. What you are doing is looking for
partial dependencies - in other words, fields that are dependent on a part of a key and
not the entire key. Because both the location code and the plant code make up the key,
you look for fields that are dependent only on location code or on plant name.
There are quite a few fields where this is the case. Location name is dependent on
location code (plant code is irrelevant in determining project name), and plant name, soil
code, and soil name are all dependent on plant number. So, take out all these fields, as
shown in the table below:
11 431
11 446
11 482
12 431
12 449
Clearly, you can't remove the data and leave it out of your database completely. You take it out,
and put it into a new table, consisting of the fields that have the partial dependency and the
fields on which they are dependent. For each of the key fields in the partial dependency, you
create a new table (in this case, both are already part of the primary key, but this doesn't always
have to be the case). So, you identified plant name, soil description and soil category as being
dependent on plant code. The new table will consist of plant code, as a key, as well as plant
name, soil category and soil description, as shown below:
You do the same process with the location data, shown below:
11 Kirstenbosch Gardens
12 Karbonkelberg Mountains
See how these tables remove the earlier duplication problem? There is only one record
that contains Kirstenbosch Gardens, so the chances of noticing a misspelling are much
higher. And you aren't wasting space storing the name in many different records. Notice
that the location code and plant code fields are repeated in two tables. These are the
fields that create the relation, allowing you to associate the various plants with the
various locations. Obviously there is no way to remove the duplication of these fields
without losing the relation altogether, but it is far more efficient storing a small code
repeatedly than a large piece of text.
But the table is still not perfect. There is still a chance for anomalies to slip in. Examine
the table below carefully:
Another anomaly
The problem in the table above is that the Restio has been associated with Sandstone,
when in fact, having a soil category of B, it should be a mix of sandstone and limestone
(the soil category determines the soil description in this example). Once again you're
storing data redundantly. The soil category to soil description relationship is being
stored in its entirety for each plant. As before, the solution is to take out this excess data
and place it in its own table. What you are in fact doing at this stage is looking for
transitive relationships, or relationships where a nonkey field is dependent on another
nonkey field. Soil description, although in one sense dependent on plant code (it did
seem to be a partial dependency when we looked at it in the previous step), is actually
dependent on soil category. So, soil description must be removed. Once again, take it
out and place it in a new table, along with its actual key (soil category) as shown in the
tables below:
Plant data after removing the soil description
431 Leucadendron A
446 Protea B
482 Erica C
449 Restio B
A Sandstone
B Sandstone/limestone
C Limestone
You've cut down on the chances of anomalies once again. It is now impossible to
mistakenly assume soil category B is associated with anything but a mix of sandstone
and limestone. The soil description to soil category relationships are stored in only one
place - the new soil table, where you can be much more certain they are accurate.
Often, when you're designing a system you don't yet have a complete set of test data
available, and it's not necessary if you understand how the data relates. This article has
used the tables and their data to demonstrate the consequences of storing data in
tables that were not normalized, but without them you have to rely on dependencies
between fields, which is the key to database normalization.
Now, we will describe the process more formally, starting with moving from
unnormalized data (or zero normal form) to first normal form.
Database Normalization: 1st Normal Form
Tables are in 1st normal form if they follow these rules:
What this means is that data must be able to fit into a tabular format, where each field
contains one value. This is also the stage where the primary key is defined. Some
sources claim that defining the primary key is not necessary for a table to be in first
normal form, but usually it's done at this stage and is necessary before we can progress
to the next stage. Theoretical debates aside, you'll have to define your primary keys at
this point
Although not always seen as part of the definition of 1st normal form, the principle of atomicity is
usually applied at this stage as well. This means that all columns must contain their smallest
parts, or be indivisible. A common example of this is where someone creates a name field,
rather than first name and surname fields. They usually regret it later.
So far, the plant example has no keys, and there are repeating groups. To get it into 1st
normal form, you'll need to define a primary key and change the structure so that there
are no repeating groups; in other words, each row / column intersection contains one,
and only one, value. Without this, you cannot put the data into the ordinary two-
dimensional table that most databases require. You define location code and plant code
as the primary key together (neither on its own can uniquely identify a record), and
replace the repeating groups with a single-value attribute. After doing this, you are left
with the structure shown in the table below (the primary key is in italics):
Location code
Location name
Plant code
Plant name
Soil category
Soil description
Location code
Location name
Plant code
Plant name
Soil category
Soil description
For an attribute to be only dependent on part of the primary key, the primary key must
consist of more than one field. If the primary key contains only one field, the table is
automatically in 2nd normal form if it is in 1st normal form
Let's examine all the fields. Location name is only dependent on location code. Plant
name, soil category, and soil description are only dependent on plant code (this
assumes that each plant only occurs in one soil type, which is the case in this example).
So you remove each of these fields and place them in a separate table, with the key
being that part of the original key on which they are dependent. For example, with plant
name, the key is plant code. This leaves you with the tables below:
Plant code
Location code
Plant table
Plant code
Plant name
Soil category
Soil description
Location table
Location code
Location name
The resulting tables are now in 2nd normal form.
Plant code
Location code
Plant table
Plant code
Plant name
Soil category
Soil description
Location table
Location code
Location name
If a table only contains one non-key attribute, it is obviously impossible for a non-key
attribute to be dependent on another non-key attribute. Any tables where this is the
case that are in 2nd normal form are then therefore also in 3rd normal form.
As only the plant table has more than one non-key attribute, you can ignore the others
because they are in 3rd normal form already. All fields are dependent on the primary
key in some way, since the tables are in second normal form. But is this dependency on
another non-key field? Plant name is not dependent on either soil category or soil
description. Nor is soil category dependent on either soil description or plant name.
However, soil description is dependent on soil category. You use the same procedure
as before, removing it, and placing it in its own table with the attribute that it was
dependent on as the key. You are left with the tables below:
Plant code
Location code
Plant table
Plant code
Plant name
Soil category
Soil table
Soil category
Soil description
Location table remains unchanged
Location table
Location code
Location name
All of these tables are now in 3rd normal form. 3rd normal form is usually sufficient for most tables
because it avoids the most common kind of data anomalies. It's suggested getting most tables you
work with to 3rd normal form before you implement them, as this will achieve the aims of
normalization listed in Database Normalization Overview in the vast majority of cases.
The normal forms beyond this, such as Boyce-Codd normal form and 4th normal form, are rarely
useful for business applications. In most cases, tables in 3rd normal form are already in these
normal forms anyway. But any skilful database practitioner should know the exceptions, and be able
to normalize to the higher levels when required.
Table 1 Table 2
ProductCode Description Price (Php) Unit InvoiceCode InvoiceLine ProductCode etsy
A150 Cement 220.00 bag PO20 1 A150 10
Student ee
The network database model was a progression from the hierarchical database
model and was designed to solve some of that model's problems, specifically
the lack of flexibility. Instead of only allowing each child to have one parent, this
model allows each child to have multiple parents (it calls the
children members and the parents owners). It addresses the need to model
more complex relationships such as the orders/parts many-to-many relationship
mentioned in the hierarchical article. As you can see in the figure below, A7 has
two members, B7 and B2. B7. is the owner of C7, C2, C3 and C4. However, in
this model, C4 has two owners, B7 and B2.
Of course, this model has its problems, or everyone would still be using it. It is
more difficult to implement and maintain, and, although more flexible than the
hierarchical model, it still has flexibility problems, Not all relations can be
satisfied by assigning another owner, and the programmer still has to
understand the data structure well in order to make the model efficient.
Understanding the Relational Database Model
The relational database model was a huge leap forward from the network
database model. Instead of relying on a parent-child or owner-member
relationship, the relational model allows any file to be related to any other by
means of a common field. Suddenly, the complexity of the design was greatly
reduced because changes could be made to the database schema without
affecting the system's ability to access data. And because access was not by
means of paths to and from files, but from a direct relationship between files,
new relations between these files could easily be added.
In 1970, when E.F. Codd developed the model, it was thought to be impractical.
The increased ease of use comes at a large performance penalty, and the
hardware in those days was not able to implement the model. Since then, of
course, hardware has taken huge strides to where today, even the simplest
computers can run sophisticated relational database management systems.
Table1
ProductCode Description Price(Php) Unit
Table2
InvoiceCode_ InvoiceLine ProductCode Qty
PO20 1 A150 10
PO21 2 A125 15
Relational Databases: Basic Terms
The relational database model uses certain terms to describe its components:
« Data are the values kept in the database. On their own, the data means
very little. ca 684-213 is an example of data in a DMV (Division of Motor
Vehicles) database.
« Information is processed data. For example, ca 684-213 is the car
registration number of a car belonging to Lyndon Manson, in a DMV
database.
e A database is a collection of tables, also called entities.
« Each table is made up of records (the horizontal rows in the table, also
called tuples). Each record should be unique, and can be stored in any
order in the table.
e Each record is made up of fields (which are the vertical columns of the
table, also called attributes). Basically, a record is one fact (for example, one
customer or one sale).
¢ These fields can be of various types. Generally, types fall into three kinds:
character, numeric, and date. For example, a customer name is a character
field, a customer's birthday is a date field, and a customer's number of
children is a numeric field.
e The range of allowed values for a field is called the domain (also called
a field specification). For example, a credit card field may be limited to only
the values Mastercard , (Visa and Amex.
¢ A field is said to contain a nul/ value when it contains nothing at all. Null
fields can create complexities in calculations and have consequences for
data accuracy. For this reason, many fields are specifically set not to contain
null values.
e A key accesses specific records in a table.
e An index is a mechanism to improve the performance of a database.
Indexes are often confused with keys. Indexes are, strictly speaking, part of
the physical structure, and keys are part of the logical structure. You'll often
see the terms used interchangeably, however, including throughout this
Knowledge Base.
e A view is a virtual table made up of a subset of the actual tables.
« A one-to-one (1:1) relationship is where for each instance of the first table in
a relationship, only one instance of the second table exists, An example of
this would be a case where a chain of stores carries a vending machine.
Each vending machine can only be in one store, and each store carries only
one vending machine.
Sculptor Sculpture
Sculpts ——O<
« A many-to-many (M:N) relationship occurs where, for each instance of the
first table, there are many instances of the second table, and for each
instance of the second table, there are many instances of the first. For
example, a student can have many lecturers, and a lecturer can have many
students.
Student Lecturer
>——
Is taught by ——<
« A mandatory relationship exists where for each instance of the first table in
a relationship, one or more instances of the second must exist. For
example, for a music group to exist, there must exist at least one musician
in that group.
e An optional relationship is where for each instance of the first table in a
relationship, there may exist instances of the second. For example, if an
author can be listed in the database without having written a book (in other
words, a prospective author), that relationship is optional. The reverse isn't
necessarily true though. For example, for a book to be listed, it must have
an author.
e Data integrity refers to the condition where data is accurate, valid, and
consistent. An example of poor integrity would be if a customer telephone
number is stored differently in two different locations. Another is where a
course record contains a reference to a lecturer who is no longer present at
the school. Database normalization is a technique that assists you to
minimize the risk of these sorts of problems.
Relational Databases: Table Keys
A key, or index, as the term itself indicates, unlocks access to the tables. If you
know the key, you know how to identify specific records and the relationships
between the tables.
Each key consists of one or more fields, or field prefix. The order of columns in
an index is significant. Each key has a name.
A primary key (PK) is a candidate key that has been designated to identify
unique records in the table throughout the database structure.
A surrogate key is a primary key that contains unique values automatically
generated by the database system - usually, integer numbers. A surrogate key
has no meaning, except uniquely identifying a record. This is the most common
type of primary key.
Foreign keys allow for something called referential integrity. What this means is
that if a foreign key contains a value, this value refers to an existing record in
the related table. For example, take a look at the tables below:
Lecturer table Course table
Systems Software 3
Relational Databases: Views
Views are virtual tables. They are only a structure and contain no data. Their
purpose is to allow a user to see a subset of the actual data. A view can consist
of a subset of one table. For example, the student view, below, is a subset of
the student table.
ye fe(-Tel ms Student Table
Grade Surname
Grade
Address
Telephone
Student View Student Table Course Table Grade Table
Address
Telephone
Database Design
» Phase 1: Analysis
» Phase 2: Conceptual Design
# Phase 3: Logical and Physical Design
= Phase 4: Implementation
= Phase 5: Testing
= Phase 6: Operation
» Phase 7: Maintenance
4&2 Database Normalization
Bem
Database
Normalization
INF
~s
2NF
M
SNF
BEY oo
=F. 7
Database Normalization : Edgar F. Codd, was the inventor
of the relational model . He also introduced the concept of
database normalization which was based on his Relational
Model. He proposed 1NF, 2NF And 3 NF normal forms.
Developed in the 1970's by E.F. Codd, database normalization is standard
requirement of many database designs.
Normalization is a technique that can help you avoid data anomalies and other
problems with managing your data.
It consists of transforming a table through various stages: 7st normal form, 2nd
normal form, 3rd normal form, and beyond.
It aims to:
Imagine you are working on a system that records plants placed in certain
locations, and the soil descriptions associated with them.
The location: The location:
Kirstenbosch
11 431 Leaucadendron | A Sandstone
Gardens
Karbonkelberg
12 . 431 Leucadendron |A Sandstone
Mountains
Location ; Soil ; 7
Location name Plant name Soil description
code category
Kirstenbosch
11 431 Leucadendron | A Sandstone
Gardens
Kirstenbosch
11 431 Leucadendron | A Sandstone
Gardens
Kirstenbosch .
11 446 Protea B Sandstone/limestone
Gardens
i h
1 aaa 482 | Erica Cc Limestone
Gardens
Karbonkelberg
12 . 431 Leucadendron | A Sandstone
Mountains
Location ; Soil ; —
moter lle emar lil a Umar) Soil description
code category
Kirstenbosch
11 431 Leucadendron | A Sandstone
Gardens
Kirstenbosh .
11 446 Protea B Sandstone/limestone
Gardens
Kirstenbosch . .
11 482 Erica C Limestone
Gardens
Karbonkelberg
12 . 431 Leucadendron | A Sandstone
Mountains
Karbonkelber
12 g 449 Restio B Sandstone/limestone
Mountains
Removing the fields not dependent on the entire key
11 431
11 446
11 482
tz 431
12 449
Creating a new table with location data Creating a new table with location data
Plant code Plant name Soil category Soil description Location code Location name
Plant code Plant name Soil category Soil category Soil description
449 Restio B
Plant data displayed as a tabular report
Kirstenbosch
11 431 Leaucadendron | A Sandstone
Gardens
Protea Sandstone/limestone
Erica Limestone
Karbonkelberg
. 431 Leucadendron | A Sandstone
Mountains
Removing the fields not dependent on the entire key
Restio Sandstone/limestone
449 Restio B
Creating a new table with location data Creating a new table with the soil description