Topic 2 Learner Guide - Kingscliff & Murwillumbah IT · 2016-01-20 · Relationship Diagrams...

ICTDBS403

Create basic databases

Topic 2 Learner Guide

© Copyright, 2016 by North Coast TAFEnow

Date last saved: 20 January 2016 by Amanda Walker Version: 1.0 # of Pages = 31

John Chapman and Amanda Walker – Content writer and course

adviser

TAFEnow Resource Development Team – Instructional and graphic

design

Copyright of this material is reserved to the Crown in the right of the State of New South Wales.

Reproduction or transmittal in whole, or in part, other than in accordance with the provisions of the Copyright Act, is

prohibited without written authority of North Coast TAFEnow.

Disclaimer: In compiling the information contained within, and accessed through, this document ("Information")

DET has used its best endeavours to ensure that the Information is correct and current at the time of publication but

takes no responsibility for any error, omission or defect therein. To the extent permitted by law, DET and its

employees, agents and consultants exclude all liability for any loss or damage (including indirect, special or

consequential loss or damage) arising from the use of, or reliance on, the Information whether or not caused by any

negligent act or omission. If any law prohibits the exclusion of such liability, DET limits its liability to the extent

permitted by law, to the re-supply of the Information.

Third party sites/links disclaimer: This document may contain website contains links to third party sites. DET is not

responsible for the condition or the content of those sites as they are not under DET's control. The link(s) are

provided solely for your convenience and do not indicate, expressly or impliedly, any endorsement of the site(s) or

the products or services provided there. You access those sites and use their products and services solely at your

own risk.

Contents Topic 2 – Data modelling ........................................................................................................ 1

Entity relationship diagrams ............................................................................................................................. 2

Preparing models ................................................................................................................................................17

Data dictionaries .................................................................................................................................................19

Preparing documentation for the client ....................................................................................................20

Client review and approval .............................................................................................................................22

Summary ................................................................................................................................................................22

Suggested answers to Activities ...................................................................................................................23

Topic 1 – Data modelling Topic 2 will provide you with information about how you can model a database. Database

modelling is used in the design of a database; specifically we will be covering Entity-

Relationship Diagrams (ERD).

To understand this you will need to:

> Design an entity-relationship (ER) diagram to model the relationships between the

entities and attributes the database will hold

> Develop the primary and foreign keys to link the entities

> Develop a data dictionary

> Complete documentation and submit it to the appropriate person for approval

1 | P a g e I C T D B S 4 0 3 _ T O P I C 2 _ L G _ V 1 . 0

T A F E n o w

Entity relationship diagrams

Entity Relationship Diagrams (ERD) are used to model databases. There are three levels of

data modelling:

> conceptual

> logical

> physical.

Each of these is completed in order and they each build on one another, thus becoming more

complex as the design approaches database build. The detail in each model is shown in the

table below:

Table 1

Conceptual Logical Physical

Entity names

Relationships

Attributes

Keys

Table names

Column names

Data types

Indexes

Integrity constraints

Views

Why have multiple models?

The models each have a different purpose. This provides for the ongoing analysis from

conception to development. The models separate the physical from the conceptual and

logical, therefore as technologies change there may be no need to update the earlier models.

The physical implementation may be very different to the logical model, while still carrying

out the initial objectives as set forth in the conceptual model.

2 | P a g e I C T D B S 4 0 3 _ T O P I C 2 _ L G _ V 1 . 0 T A F E n o w

Different notations.

There are a number of different notations that are available for developing ERD. Often which

is used will depend on what the preference of the client is or the standard your employer may

set. In this unit we will be using the Information Engineering style.

We will be using the Information Engineering Style (or crows foot) in this unit. The following

are the possible combinations you may use when creating an ERD using the Information

Engineering Style:

Figure 1 (Jewell, 2005)

Conceptual model

The conceptual model is the simplest and earliest of the database models. It shows major

entities and their relationships to one another, i.e. one to one, one to many or many to many.

It should be suitable for use by technical and non-technical stakeholders.

The conceptual model shows data used in the enterprise independent of all physical

limitations, including which database management system is used, how many users there are

and what capacity the system will have. It is prepared in language that is used by the

customer, it may be inclusive of terms that are specific to their business but will not include

technical terms or jargon. It describes the functions of the system and is linked to the

requirements document.


T A F E n o w

Entities

At this point it is important that you understand what an Entity is. Entities are things that you

might wish to store information about, they include for example:

> Tangibles (e.g. equipment)

> Concepts (e.g. account)

> People (e.g. staff)

> Events (e.g. sale)

> Places (e.g. office location)

An instance of an entity is a single occurrence. For example if Bill Smith worked for Platinum

Pty Ltd then Bill Smith is a single instance of the entity STAFF for that business in their HR

system.

When interviewing clients nouns that crop up regularly are often entities.

When you are naming entities it is important that you are consistent with the naming, to do

this it is useful to apply the following standards:

> Be accurate, name things functionally and technically accurately

> Be concise, as few words as possible

> Be unique, don’t use the same word for multiple entities or attributes

> Be atomic, represent a single concept

> Contain only letters, numbers and separators

> Use names rather than abbreviations where possible

> Be consistent, if you use _ to separate words do so everywhere e.g. SHOP_ITEM,

ONLINE_ITEM

Relationships

Relationships are used to show that entities relate to one another. You should use consistent

naming across the database model, the following are recommended standards:



> Typically noun (entity) verb noun (entity) e.g. STUDENT enrolls_in COURSE


> Label in both directions showing the name closest to the entity from which it will be read

e.g.

Cardinality

Cardinality is how one entity relates to another entity, in some types of modelling this is

referred to as multiplicity. The following are some key features of cardinality in ERDs:

> Maximum Cardinality refers to the maximum number of instances of one entity that can

be associated with an instance of another.

> Minimum Cardinality refers to the minimum number of instances of one entity that can

be associated with an instance of another.

> For example one PERSON may have zero or more instances of PET and one PET may have

one or more owners.

> The trick is to determine one side at a time, in each case you are considering the

association to one instance of the other.

If you find it hard ask yourself the question using a single instance, for example ‘How many

owners could Jack the dog have?’

The following are some standards that are typically applied to conceptual models:

> Have as many entities as necessary, but break into subject areas of 10-15 entity

maximums

> Entities must have the same name regardless of which part of the model they are shown

on

> Each part of the model must have a unique name and version number

> Every entity should have at least one relationship

> Many to many relationships are supported


T A F E n o w

LEARNING ACTIVITIES ACTIVITY 1

Complete the following sentences to provide a text description of the following diagram,

specifically addressing cardinality:

A salesperson makes

A contact by


Which of the following is not something that you should consider when naming entities?

a. Be accurate

b. Be unique, don’t use the same word for multiple entities or attributes

c. Use the plural (e.g. Sales)

d. Contain only letters, numbers and separators


Logical model

The logical data model shows how data is used in a given enterprise based on a specific

model of data storage (e.g. relational) but independent of a given DBMS and all other physical

considerations.

The logical model varies from the conceptual model in the following ways:

> It includes Attributes and details about them such as data types, null status and length

> It includes Primary Keys and Foreign Keys

> It is Normalised

Attributes

In ERDs attributes are items we hold in relation to an entity, e.g. the entity INVOICE may have

Attributes including INVOICENO, INVOICEDATE, INVOICEAMOUNT. Sometimes these are

called data items. During analysis some attributes may be found not to be required,

potentially they need to be separated to a new entity (i.e. to normalise).

You should use consistent naming of attributes across the database model, the following are

recommended standards:

> Be accurate, name things functionally and technically accurately


> Be unique, don’t use the same word for multiple entities or attributes

> Be atomic, represent a single concept

> Contain only letters, numbers and separators


> Be consistent if you use NO for number do that everywhere (e.g. CLASS_NO,

PAYMENT_NO)

The following should be considered with respect to the attributes you have identified.

> Significant? Only include things that will be useful to users.

> Direct not derived? Derived attributes are available elsewhere in the database (e.g. age is

able to be derived from date of birth)

> Nondecomposable? Something with repeating groups is not an attribute


T A F E n o w

> Consistent data type? For example all dates, you cannot include names in the date of

birth field.

When you define an attribute you need to assign it a Data Type. Common data types include

the following:

> INTEGER or NUMBER – any signed or unsigned number

> FLOAT or DECIMAL – a signed number with decimal places

> DATE – date only

> DATETIME – date and time

> TIMESTAMP – a unique reference to a point in time

> CHAR/CHARACTER/TEXT – character string

> IMAGE/FILE

A data type ‘tells’ you what sort of data will be stored in the attribute. The following are key

considerations in assigning data types:

> Logical models are free of physical limitations so at this stage it is sufficient to use a set of

standard terms that are not associated with the Database Management System (DBMS)

being used.

> It is best though to use types that are commonly used by a variety of DBMS (in this case

Relational DBMS) to save effort/rework when you get to physical design.

> For the physical design the Data Type must correspond with the available data types in

the specific DBMS.

It is common to include the following additional details associated with each attribute:

> Numbers : Minimum, Maximum, Length, Signed/Unsigned flag

> Characters: Maximum Length

> Images/Files : anticipated file types

> Null/Not Null flag (or Mandatory flag)

Primary keys

Primary keys are used to identify and locate data within a database. Each entity must have a

primary key. Primary keys are used to uniquely identify an instance of the entity. Primary

keys are used to directly access an instance of the entity e.g. to access a specific supplier in the

SUPPLIER entity you would use the associated primary key e.g. SUPPLIER_NO. A Primary Key

may be a group of unique attributes that identify a record.


There are a number of different types of primary keys, as follows:

> Simple – a single attribute that uniquely identifies the instance of the entity

> Compound – two or more attributes that uniquely identify an instance of the entity

> Hierarchic or Composite – one or more foreign keys and a qualifying non-foreign key

attribute. For example: STUDENTS study UNITS and UNITS have GRADES so GRADES

might use STUDENTID, UNITNO and GRADENO where GRADENO is a consecutive number

sequence for each unique combination of STUDENTID and UNITNO

The following is another example of a composite key: If invoice numbers are allocated each

financial year sequentially starting at 1 then YEAR and INVOICENO would together be unique:

> YEAR = 2012 would exist for all invoices that year

> INVOICENO =1 would exist for the first invoice each year

but

> YEAR = 2012 and INVOICENO = 1 together exists only once for all records it is a unique

reference to a single record (i.e. a primary key)

Foreign keys

When there is a relationship between two entities there needs to be a foreign key in each

entity to link instances in one entity to instances in the other.

For example:

> Primary Key for ORDER is ORDERNO

> Primary Key for CUSTOMER is CUSTOMERNO

> The CUSTOMERNO included in the ORDER entity is used to locate the customer

associated with the order.

Normalisation

Normalisation is the process of organising data in the database.

Normalisation is completed by applying sets of rules in stages, these stages are known as first

normal form (1NF), second normal form (2NF) etc. We will stop at 3NF for the purpose of this

unit that relates to basic databases, you can go on to 6NF. Often if you comply with 3NF you

will comply with 4NF and 5NF but not 6NF.


T A F E n o w

The goal of normalisation is to:

> Protect the data

> The database more flexible by eliminating redundancy and inconsistent dependency.

One of the key purposes of normalisation is to remove or reduce data redundancy. Data

redundancy is basically the duplication of data for various different systems. The issues with

redundant data include:

> Duplication of maintenance

> Potential of update in a subset of locations impacting data integrity

> Storage implications.

First normal form

First normal form is achieved when the following conditions are met:

> when all entities have a unique identifier or key

> when every column in every table contains only a single value (i.e. doesn’t contain a

repeating groups or composite fields).

To ensure that this is the case we:

> identify/create a primary key per table

> split any composite fields into multiple separate fields

> move any repeating groups into separate tables where each repetition will be a single

row in the table - identified by a unique key.

The following is an example:

> An entity contains the attributes Order Date, Ordered By, Item and Order Amount – none

of these uniquely identifiers the row, we need to add OrderID as a unique primary keyl

> Ordered By, according the client needs, contains both the customer name and contact

details, this should be separated into the contact details (e.g. name, address, suburb,

state, postcode and phone number) in separate fields.

> Item and Amount may repeat if the order is for many different items, these then need to

be moved into a new entity (e.g. Order Items).


In the following you can see that Items are contained within the table:

Orders

OrderID (PK) ItemNo ItemNo2 ItemNo…

1 1000 1001 …

> They should be separated and have an ItemNo or similar along with the OrderID as the

Primary Key.

> OrderID will be a foreign key to the Order table too.

Second normal form

Second normal form is achieved when the following conditions are met:

> when the table is in First Normal Form

AND

> every non-primary key column in the table must depend on the entire primary key, not

just part of it (if there is a composite key)


> comply with first normal form

> move any field that is dependent on only part of the key into a separate table

For example the primary key you have identified for a table is Order ID and Order Item

Number; this is the table that contains order items. If you included Date Ordered in that table

it would be dependent only on the Order ID not the Order Item Number therefore you need

to move Date Ordered to a table with only Order ID as the primary key.


T A F E n o w

In the following you can see this example shown using the table format:

Orders

OrderID (PK) ItemNo (PK) DateOrdered …

1 1000 1/1/2012

1 1001 1/1/2012

The Order ID will be the same for each item, so it will be repeated and redundant. The

solution:

Orders

OrderID (PK) DateOrdered …

1 1/1/2012

1 1/1/2012

Order Items

OrderID (PK) ItemNo (PK) …

1 1000

1 1001


Third normal form

Third normal form is achieved when the following conditions are met:

> when the table is in First and Second Normal Form AND

> each column that isn't part of the primary key doesn't depend on another column that

isn't part of the primary key


> comply with first and second normal form

> move any columns that depend on a column other than the primary key into another

table

The following table relates to the example below:

Orders

OrderID (PK) Customer Name Customer Address Customer Suburb Customer …

1 Bill Smith 12 White St Ryde …

2 Bill Smith 12 White St Ryde …

Looking at this example:

> The Customer Details are not directly related to the Order

> They could stand alone and therefore should be moved to a separate table

> In that new table they would have a foreign key relating them to the Orders for the

customer.

Third normal form may be too much.

Sometimes if you normalise to 3NF the database may become very inefficient, splitting things

like SUBURB, STATE and POSTCODE because of their interdependency may make loading data

to screens, reports, letters etc. too inefficient.

Consider each case and what the data will be used for as you encounter it.


T A F E n o w


Q1. Does the Logical model include all the different fields that will be stored in the database?

Q2. Look at the following example Logical model and answer the questions below:

1 What do you think this system might be?

2 Is it possible to have an Item that does not have a Type recorded for it in the system?

3 According to this model can the same Patron both Loan and Reserve a particular item?

4 Can a Patron loan more than one item?

5 Can a Patron reserve more than one Item?


There are 2 parts to the Logical Data Model:

> A diagram called the logical data structure (LDS)

> A set of associated textual descriptions that explain each part of the diagram.

Unless directed otherwise, you should produce both of these elements whenever you are

asked to produce a Logical Model for a client.

The following are the steps involved in logical modelling of a relational database:

1 Identify the entities – removing features not compatible with the data model (i.e.

relational model). In Conceptual Data Modelling we included entities, the same definition

applies. Now it is time to recheck the entities you identified. Initially ask yourself:

> Is there more than one occurrence of this concept?

> Is each occurrence uniquely identifiable?

> Do we need to hold data about this concept?

> Is this thing relevant to the system I am designing? (i.e. the business may have sales

but if this is the HR system that is likely not relevant)

2 Identify the attributes

3 Model the relationships – normalise and verify cardinalities

4 Choose Primary Keys – good keys are:

> Unique

> Non-null

> Data-less

> Never change

If your key does not meet this then create an arbitrary key (i.e. a key that has been created

solely to be a unique identifier, these are generally 1, 2, 3 etc.

5 Check the model


T A F E n o w


What two separate parts must be provided when you are asked to supply a Logical model?

1

2

Physical model

The Physical Model is representative of the physical implementation of the database. In

reality often this is done in the DBMS.

In large scale projects you should have documents including:

> Physical Database Model

> Tables

> Columns

> Data types

> Keys

> Constraints

> Indexes

> Views

> A word processed document that outlines other details like the Security, Disk Space

Requirements and Backups

> Data Dictionary – updated from logical design to include additional physical

characteristics

Given that this unit is associated with basic databases we will be limiting our attention to the

tables, columns, data types and keys associated with a database only. The other aspects of

the Physical Database Model are associated with more complex databases and will not be

covered within this unit. Therefore our physical model will be very close to our logical model,

except that the data types must correspond with the database management system we are

using.


Data Types

We will be using MySQL in this unit, the following are the data types that are used within

MySQL and therefore which you would need to use in your physical model.

REFERENCE REFERENCE 1

MySQL Reference Manual includes details about the available data types and pros and cons of

using various options. (MySQL, n.d.)


This table will contain the data types you are most likely to use in MySQL in this unit of study.

Complete the following table, use the web reference above to find the answers if you are not

familiar with these data types.

Table 2

Data type Description

VARCHAR A variable string from 0 to 255 characters

SMALLINT

FLOAT

DATE

DATETIME

Preparing models

When you prepare an ERD for a client there are a number of different approaches, they

include:

> Paper and a Pencil – lacks the professional touch.


T A F E n o w

http://dev.mysql.com/doc/refman/5.6/en/data-types.html

> Products like ERwin, Smartdraw, Embarcadero's ER/Studio, Sybase's PowerDesigner,

Microsoft Visio or Popkin's System Architect.

> In the DBMS (e.g. SQLServer 7 or greater includes Database Design as does the current

version of MySQL).

Always assume that the client might not have the specific tool that you have used to prepare

the diagram and with this in mind present the diagram to the client in a common format, e.g.

PDF.


Q1. Using a pencil and paper model the following, prepare a conceptual and also a logical model:

Scenario

Peter sells vegetables from his home garden. Peter wants to keep a database that contains details

about which of his neighbours’ purchased which vegetables when he has them available. The

most important things for Peter are that he can:

> Know which neighbour lives where.

> Know the names of his neighbours. Note there may be multiple neighbours at one address,

Peter wants to know all their names.

> Know which produce they purchased.

> Know when they purchased it (i.e. date).

Peter does not want to know about how much they purchased on a given day, just whether they

purchased any of that produce that day.

Q2. Take the model that you completed on paper in Q1 and now prepare it in a suitable electronic

format. Be sure to use Information Engineering notation.

If you do not have access to a suitable tool, you can make use of available products online, for

example Draw.io or if you wish to use Microsoft Visio please contact your Facilitator to arrange

Microsoft Dreamspark access if you do not have this already.


https://www.draw.io/

mailto:[email protected]?subject=Request%20for%20Dreamspark%20Account

Data dictionaries

Data Dictionaries capture definitions for the various components of the system. They allow

participants in the project to access details about the system similarly to a standard English

dictionary.

Data dictionaries, in this context, have the following attributes for data element related

entries (elements is another name that refers to attributes or columns):

> Data type

> Length

> Range

> Discrete values (i.e. where only a specific set of values are valid)

> Required (or Allows Nulls)

> A description of the element.

Data dictionaries can be formatted in a number of different ways, most commonly now they

are produced in spreadsheets or for larger projects in one of many tools that are designed to

prepare and maintain data dictionaries.

The following is an example of a data dictionary:


T A F E n o w


Refer to the scenario in Activity 6 and prepare a data dictionary that covers the elements in the

Logical database you designed. This may be best completed in a spreadsheet.

Preparing documentation for the client

Present your diagrams professionally, even if you have only a single conceptual model to

present it should be presented consistently with other documents and conform with

presentations guidelines. Generally it is accepted that the ERDs will be provided to the client

as part of a document, not as stand-alone diagrams.

The design document will typically include the following:

> Introduction/Document Purpose

> Standards Used

> Assumptions, if you have made any be sure to detail them.

> Interpreting the Model (i.e. instructions that enable the client to understand what the

diagram means)

> ERD (may be a single model or a number of models depending on the complexity of the

database and the standards being followed)

> Data Dictionary

> Signoff facilities inbuilt or attached (e.g. review request).

It is significant to note at this point that when the database is basic it may be possible to

produce only a single ERD that takes into consideration all the aspects of the three models.

This is not recommended for more complex databases. In the event that you do produce only

a single ERD the following are some important considerations:

> Double check your ideas with the client before commencing, make sure that the

concepts you would have included in your conceptual diagram are well founded


> Develop the ERD by working through what you would have done if you prepared the

three separate models

> Avoid rework by normalising as early as possible and using data types that match with

your database management system

Version Control

It is important that each ERD is version controlled, some reasons for this are:

> So you know why, how and when changes were made

> So you know who requested a change

> So you know which version the changes applied in

> So you can cross check changes against system updates

> So stakeholders can review only updates that have been made since the last version,

rather than the entire document again

Internal review

Before the document is released to the client it should be reviewed internally, preferably by

someone other than the person who prepared the document, however sometimes this is not

possible e.g. in the case of a single contractor. The review should include the following:

> Systematically check across all source documents (forms, reports, and minutes of

meetings) that have not been superseded.

> Start with the earliest documents (e.g. initial request) and move to most recent

documents (e.g. session minutes).

> Check with the client if there is any ambiguity or where documents are contradictory

> If you have an entity with only one attribute you need to seriously consider why, is it not

an attribute of another entity? It is likely there is an error if this is the case.


If you were working on a basic database and you choose to complete just a single ERD rather than

all three models which of the three models would the one ERD resemble?


T A F E n o w

Client review and approval

As with all formal documents produced during the design phase the ERD should be reviewed

by the client and their formal approval obtained. Refer to the review and approval section in

Notes 1 for this topic if you feel unsure about how to approach review and approval.

Most importantly you should:

> Ensure the client understands the diagrams they are being asked to review.

> Provide details where the client can seek assistance during the review.

> Obtain the approval in writing if possible, if not confirm the verbal approval and keep the

approval on record.

Summary

When designing a database there are three different models that are prepared in stages, the

conceptual model, the logical model and the physical model.

The conceptual model is a high level model that enables you to picture how the main

elements or concepts in the database will relate to one another. The logical model takes into

account the type of database (e.g. relational) this model includes keys and attributes and is

normalised. Keys identify data in the database. Attributes are like fields, they are what you

will capture about the entity. Normalisation is the process of reducing data redundancy, this

should make the database easier to maintain and more efficient. Finally the physical model

takes into consideration all the physical requirements, including which database

management system will be used.

When you are designing a basic database it may be possible to reduce the number of

diagrams that are prepared, however you should consider the steps required to produce each

diagram so that you do not overlook any requirements of good database design.


Suggested answers to Activities

Activity 1

A sales person makes none, one or many contacts.

A contact is related to one and only one sales person.

Activity 2

Use the Plural does not apply. You should use the singular e.g. SALE not SALES

Activity 3

Q1. – No – Fields are called columns in a database and these are not included until the

physical ERD.

Q2.

1 A library management system

2 Yes the relationship shows that an ITEM may have zero or one TYPE

3 Yes there is nothing to limit the PATRON from both having an ITEM on LOAN and RESERVE

4 Yes a PATRON may LOAN zero, one or many ITEMS

5 Yes a PATRON may RESERVE zero, one or many ITEMS

Activity 4

1 A diagram called the Logical Data Structure (LDS).

2 A set of associated textual descriptions that explain each part of the diagram.


T A F E n o w

Activity 5

Table 3

Data type Description

VARCHAR A variable string from 0 to 255 characters

SMALLINT -32768 to 32767 normal OR 0 to 65535 UNSIGNED

FLOAT A smallint with a floating decimal point

DATE YYYY-MM-DD

DATETIME YYYY-MM-DD HH:MM:SS

Activity 6

Conceptual

Note that in the conceptual model we have not resolved the many to many between person

and produce.


Logical

Remember that database design is not a precise art, your design may vary from the answer,

but take a look at this design and consider why it might vary from yours.


T A F E n o w

Activity 7

Entity Attribute Key Type Format Required Content

PERSON PERSONID PK SMALLINT Y Unique

identifier for

the person

PERSON FIRSTNAME VARCHAR(30) Y

PERSON SURNAME VARCHAR(30) Y

PERSON ADDRESSID FK SMALLINT Y

ADDRESS ADDRESSID PK SMALLINT Y

ADDRESS ADDRESS1 VARCHAR(50) Y

ADDRESS ADDRESS2 VARCHAR(50)

ADDRESS SUBURB VARCHAR(30) Y

PERSONPRODUCE PERSONID FK SMALLINT Y

PERSONPRODUCE PRODUCEID FK SMALLINT Y

PERSONPRODUCE DATE DATE DDMMYYYY Y

PRODUCE PRODUCEID PK SMALLINT Y

PRODUCE PRODUCENAME VARCHAR(50) Y

Note the following:

> The Address is separate from the person due to normalisation, otherwise where there are

multiple people at the same address the address would be repeated and cause

redundancy.

> Given this is a neighbourhood I have not included state, but if this was a border town like

Tweed Heads that might be necessary.

> The Required value relates to whether the value is required if there is an entry in the

table, therefore if any value is entered in the PERSONPRODUCE table then all fields in that

entity are required.

> It is possible that your model could be different that does not make it wrong, consider

why it is different and whether it meets the needs of Peter.


Activity 8

The ERD would typically be representative of the physical model, as you would need to have

included the attributes of each model in order to develop the single model. Therefore given

that the physical model is produced last and is the most complete of all models the single ERD

would need to include physical characteristics such as data types.


T A F E n o w

Topic 2 Learner Guide - Kingscliff & Murwillumbah IT · 2016-01-20 · Relationship Diagrams...

Documents

Transcript of Topic 2 Learner Guide - Kingscliff & Murwillumbah IT · 2016-01-20 · Relationship Diagrams...