Download PowerPoint

Houston we have a problem!
 Database design left very late in the process
 Not less important than other aspects
 Typically where it always gets landed in the process!
 It makes sense to work through each layer in turn
 There is a lot to think about here that is both complex
and subtle
 Some of this will serve as revision
 Explore the difference between classes and entities
Document Standards
 Problems compounded by differing documentation
standards
 Chen notation (Peter Chen 1976)
 Crows Foot Notation
 UML
 Entity Relationship Diagrams an afterthought in UML?
 (Relational v Object Oriented Databases)
The Chen Notation
House
M
1
On
Site
 A house must be on a site
 A site may or may not have many houses
 The dots indicate the membership class of related
entities
The Crows Foot Notation
House
 No indication of membership class
Site
UML Notation
House
Site
0..*
1
 Again no indication of membership class
 Pretty much identical to class diagram
Which is Best?
 Familiarity and personal preference
 What standard you are told to use
 Which standard the software we are using i.e.
Enterprise Architect “encourages” us to use UML but
there are plug-ins for other types
 For the examples in this module we will be using the
Crows Foot notation
 Supported by Enterprise Architect allowing auto
generated code
 You get to decide what you use – be consistent
What is the Difference between a
Class and an Entity?
 It really doesn’t help much when we have two
documentation standards that look so similar
 The rectangular boxes are inevitably going to look
pretty similar until the subtleties are fully appreciated
So what are the differences?
 Classes do not persist
 Classes are ultimately implemented as objects
 When the function or program ends, the object ceases to
exist
 Entities are ultimately implemented as tables
 Tables do not vanish once the program/function has
completed
Classes have Functionality Entities
do not
clsAddressBook MyAddressBook = new clsAddressBook();
MyAddressBook.FilterByPostCode(“LE1”);
“But really – aren’t they basically
the same thing?”
 Compare the following…
 Entity framework automates much of this
Classes may have no link to any
entity
Classes may manage multiple
entities…
Customer Name
Delivery Address
Post Code
Widget Order
Order line 1 Product A
Unit Cost
Quant
Tot
Order line 1 Product B
Unit Cost
Quant
Tot
OrderTotal
More Complex Relationship
 The data for the class would be derived from multiple tables
 For example



Customer details would come from tblCustomer
Product details would come from tblProduct
There may be a stock check facility making use of tblStock
 Some elements of the invoice would never ever be stored in the
system
 For example

Order line totals and the invoice total would be calculated on the fly
 When the invoice is stored in the system the data contained in a
single object would be distributed across multiple tables.
Objects may be generated onthe fly
 LINQ (Language-Integrated Query)
 Query Language for Objects
 Similar to SQL
var queryLondonCustomers = from cust in customers where
cust.City == "London" select cust;
The Difference…
 Entities are about storing stuff
 Classes are about controlling stuff
Normalisation/De-Normalisation
Database normalization is the process of organizing the
fields and tables of a relational database to minimize
redundancy. Normalization usually involves dividing
large tables into smaller (and less redundant) tables
and defining relationships between them. The objective
is to isolate data so that additions, deletions, and
modifications of a field can be made in just one table
and then propagated through the rest of the database
using the defined relationships.
(Wikipedea)
Things to Consider
 No row order significance
shelf
A
B
product
price
butter
89
lard
37
bread
62
milk
32
We are insisting that the rows must be
sorted as above otherwise we won’t know
what shelf a product is on
No Column Order Significance
student#
0427h
name
smith
david
ivan
We are assuming that the columns must
always be in this order otherwise we won’t
know the person’s name.
Each attribute value must have
only a single value
car
astra
make
vauxhall
engine-size
1100,1300
No Duplication
box#
contents
colour
31
sugar
brown
47
flour
white
9
rice
white
47
flour
white
103
sugar
white
Always Decompose Many to Many
Relationships
Order
Order
Product
Order Line
Product
One to One Relationships
 Do not exist (probably).
A
B
De-Normalisation
 Some times we deliberately step back from a
normalised database to meet other requirements
 E.g. System response time
Other Places to Inform our Entity
Design
 Smoke and mirrors prototype
 Class diagram
 Sequence diagram