NIAM History
prior to 1975 -
CODASYL Heirarchical DB model based loosely on relational model of data
until Ted Codd left group and formalised relational model operations
1976 - Nijssen
1978 - Sub-types added, with NIAM evolving into knowledge representational
technique as opposed to a database tool
1982 - ISO formally recognised Conceptual Schema Diagrams as valid,
standard, method of knowledge representation
1982 - Van Bekkum published works on 'NIAM'
1983 - Wintraecken published 'NIAM bible'
1985 - Halpin and Nijssen published NIAM text
1995 - Halpin 2nd Edition of text
- This is the most
important (and difficult) step, and one of few that really require
a person.
- Consider it a
'fact-finding' mission (or rather 'fact-type finding' mission)
- We search for
examples of written communication (eg. printouts, data entry forms,
graphs, tables, charts... used by user - these provide the 'raw' material
to build an IS.
- Our aim is to
express sentences (in unambiguous formal English) in elementary form
(NOT as the conjunction of simpler facts). Facts expressed in this
form are said to be single-valied or atomic
Some terminology:
- ENTITY = basic
objects in UoD (these can be either physical/tangible or abstract)
- ENTITY TYPE =
the type of object, each example entity is an instance of one
- ROLE = every
entity plays at least one role. A role is played by at most one
entity. All entities belong to at least one logical predicate.
- UNARY FACT =
predicate(entity) eg: Olivia is_male; or is_male('Olivia')
- BINARY FACT =
predicate(entity,entity) eg: Olivia has_gender Male; or has_gender('Olivia','male')
- TERNARY FACT
= predicate(entity,entity,entity) eg: Olivia obtained VHA in
IPT; or obtained_mark_for('Olivia','IPT','VHA')
- ARITY = the number
of entities involved in a fact type
In our understanding
of facts, context is important
Sydney is_located_in
Wales (possible ambiguity?)
Q: Did you hear
about the man with the wooden leg called Smith?
A: No, what did he call the other one?
label 'Smith'
incorrectly applied to the entity 'Wooden Leg', rather than the correct
entity (a person)
Elementary Sentences
follow a syntax similar to the following:
Entity(ref)'data'|data predicate [Entity(ref)'data'|data ]
{predicate Entity(ref)'data'|data }
A: Parents and Progeny
Parents Children
--------------------------------------
Ann, Bill Colin, David, Eve
Boris, Carla Olivia, Zac
Person(firstname)'Ann' isparentof person(firstname)'Colin'
B: Love Thy Neighbor
Country Ally Enemy
--------------------------------------------
Yugoslavia Russia
USA Australia Iraq
Australia USA New Zealand
CUBA
CUBA Russia USA
Yugoslavia
Country(countryname)'Yugoslavia' hasally Country(countryname)'Russia'
Country(countryname)'USA' hasenemy Country(countryname)'Iraq'
C: It Stunts Your Growth
Smokers Nonsmokers
------------------------------
Fred Eugene
Noreen Beryl
Jim-Bob Neville
unary: Person(firstname)'Fred' issmoker
Person(firstname)'Eugene' isnonsmoker
binary: Person(firstname)'Fred' has Smokingstatus(sscode)'S'
Person(firstname)'Eugene' has Smokingstatus(sscode)'N'
D: Meetings Schedule
Club Day Hour Room
---------------------------------------------------
IPTSIG Wed 7.30 a.m 4.8
Computer Tue 3.15 p.m 4.9
Chess Fri 3.30 p.m 4.6
Club(clubname)'IPTSIG' meetson Day(daycode)'Wed'
Club(clubname)'IPTSIG' meetsat Time(ampmcode)'7.30 a.m'
Club(clubname)'IPTSIG' meetsin Room(roomnum)4.8
E: First Year Offerings
Subject CredPts Semester Enrollment Lecturer
----------------------------------------------------------------------------
CS100 8 1 500 PP
CS102 8 2 500 GR
CS112 8 1 300 TH
CS380 16 2 45 AL
assuming a subject can run in more than one semester:
Subject(subjcode)'CS100' isofferedin Semester(semnum)1 = offering
Subject(subjcode)'CS100' isworth Credit(points)8
offering istaughtby Lecturer(initials)'PP'
offering hasenrollmentof Personcount(nr)
F: Supermarket Ripoff
Item Itemcode CostPrice Markup SellingPrice
----------------------------------------------------------------------------
Kittycat200g A0350 0.35 0.44 0.79
Selsun250ml C1104 2.40 0.85 3.25
Twistee100g X0042 0.10 0.69 0.79
Product(code)'A0350' is labelled Itemname 'Kittycat200g'
Product(code)'A0350' wholesalesfor Money($)0.35
Product(code)'A0350' retailsfor Money($)0.79
Product(code)'A0350' hasmarkup Money($)0.44
G: Pets
Animal Name Sex
-----------------------------------
cat Flossie F
dog Nip M
iguana Leonard M
Animal(name)'Leonard' is of kind Animal(animalname)'Iguana'
Animal(name)'Leonard' has Gender(gendercode)'M'
H: Co-Curricular Involvement
Club Time Room Student Name Year Tut Group
-----------------------------------------------------------------------
Chess Mon 3 pm 4.5 Pizza C 6 T2
Dingo S 12 W9
Parrts O 11 B2
Debat'n Wed 4.30 pm 5.4 Nurke F 12 T2
Parrts O 11 B2
Club(clubname)'Chess' meetsat Time(ampmcode) 3.00p.m.
Club(clubname) isheldin Room(roomcode)'4.5'
Student(studentname) 'Pizza C' belongsto Club(clubname)
Student(studentname) isin Year(yearnum) 6
Student(studentname) ismemberof Tutgroup(tutgrpcode) T2
I: STUDENT RESULTS
Student Subject Rating
------------------------------------------------
Bloggs F IPT VLA
Nurke J " VLA
Paarts O HEC HA
: : :
Student(studentname)'Bloggs F' received Rating(ratingcode)'VLA' in Subject(subjcode)'IPT'
J: MANIACS ON THE ROAD
Person Licence# Cars Driven
-----------------------------------------------
Pie QT A3050 235PZN
Adams G A2245 235PZN, 108AAQ
: : :
Person(personname)'Pie QT' holds Licence(licensenumber)'A3050'
Person(personname)'Pie Qt' drives Car(regnum)'235PZN'
K: SOFTWARE SELLERS
Retailer Item Quantity Sold
------------------------------------------------------------
CompuWare SQL+ 330
ZappoPascal 330
WorPerfect6 200
SoftwareLand SQL+ 330
ZappoPascal 251
: :
Retailer(retailername)'CompuWare' sold Item(itemname)'SQL+' inquantity Tally(number)330
ORM - First
Draft of the CS
using symbols to
represent entities and roles, draw each of the sentences as separate
conceptual schema fragments. (to ensure they are correctly drawn, identify
the roles and their converse roles, and attempt to instantiate the fact
types)
Notice, E1 and E2
represent two distinct objects (entities) in the UoD, r is the relationship
(role) linking E1 to E2. r' is the role linking E2 to E1 (which in fact
is the converse of r)
IMPORTANT
- each role is played by exactly ONE entity, and an entity must play
AT LEAST ONE role. If this is not the case, we have nothing tangible
to store about the entities
'Purists' argue
that there is worth in drawing individual schema fragments for each
of the fact types represented in step 1 - I believe that most students
are able to see that entities are shared amongst sentences and can often
go straight to the first draft of the diagram
conversely, go straight
to step 3
ORM
- Eliminate Surplus
Entities and Identify Derived Facts
This step requires
you to examine each of the entities drawn in your schema, and COLLAPSE
any common (called surplus) entities. Also, indicate that fact types
are derived - place an asterisk beside the fact type if it is derived.
This will later indicate that this fact type is not to be stored,
rather it will resolve into a RULE.
The first three
steps are designed to identify the types of objects that exist in the
universe to be modelled, and the relational 'glue' that binds them together.
The next few steps are designed to specify what is possible and impossible
(ie. to constrain the objects with 'real-life' rules, so they are described
as behaving in our model UoD just as they do in the wild.
ORM - Uniqueness Constraints
WARNING: using examples
to deduce constraints requires knowledge of the UoD, or at least a little
common sense. By specifying a real-life too weakly or too strongly we
adversely affect the performance of our model. When referring to examples,
they will be significant - should any inferences be made that are not
directly supported by the examples, the underlying assumptions WILL
BE WRITTEN DOWN.
Place uniqueness
constraints ON EVERY FACT TYPE in the schema - be systematic, and check
all combinations.
A Uniqueness constraint
prohibits something from happening more than once. Uniqueness constraints
exist in many combinations:
The 'whole row'
constraint is always considered to be present - this is because NO FACT
CAN BE REPEATED - it is considered a weak constraint. If other uniqueness
constraint patterns are found, it is often left out (as redundant)
Facts can appear
in many forms. The 'nested' forms of the facts below say something different
about the populations than do the 'flattened' forms.
With the 'nested'
forms, the nest object (enrollment) exists in it's own right, and may
have a collection of 'attributes' that can be added LATER - the
flattened form is an 'all or nothing' fact type - all three entities
must be present before the fact can be stored.
INTER-FACT-TYPE
constraints are relatively common, and help us to define unique columns,
secondary and foreign keys
Given
the following significant table populations, indicate appropriate uniqueness
constraints from those illustrated:
A B C A B C A B C
a1 b1 c1 a1 b1 c1 a1 b1 c1
a2 b1 c1 a2 b2 c2 a1 b1 c2
a1 b2 c2 a1 b2 c2 a2 b1 c2
a2 b2 c1 a2 b2 c2
It is important
to investigate each combination of entity when placing uniqueness constraints
- these will translate to KEYS and INTER- TABLE CONSTRAINTS and are
therefore vital to maintain the integrity of the system.
Also, correct placement
of uniqueness constraints can help determine if the arity of the fact
types drawn is correct.
Beware also of inconsistent
constraints
