NIAM is not the
only conceptual (knowledge) representation technique.
Presented here are
2 others. All techniques have at their core the need to represent information
precisely and unambiguously. Any method has its' PRO's and CON's.
'Z'
'Z'
is not a programming language, rather it is a preciseMATHEMATICAL
specification language, relying heavily on SET NOTATION.
The
'Bank' schema below represents the BASE STATE of a database
that tracks customers in a bank.
In brief, the first
section (the pre-conditions) state that there is a set of OPEN tellers,
a teller is BUSY if the teller is serving someone, there is a queue
waiting to be served, there are others in the bank. The second section
of the Bank base state schema specifies that busy tellers are a subset
of those open, it is not possible to be in the queue and being served
at the same time, nor is it possible to be in the queue and roaming
around the bank, or being served and roaming. Further it states (redundantly?)
that the number of people in the queue is the same as the number of
places in the queue
This second schema
is termed a TRANSITION or STATE SCHEMA, and in this case it represents
the process where a teller says "next please". The first section (the
pre-conditions) states that this action produces a change in the BANK
BASE STATE SCHEMA, and that an input (the teller number) is required
as input to the process. The remainder of the schema states that the
teller must be one of the ones that is open, the teller is not allowed
to be busy already, there must be someone in the queue, the person at
the head of the queue moves to be busy with the teller, the queue reforms
after the departure of the head person, the number and id of tellers
open remains unchanged, and the others roaming around in the bank remains
unchanged.
'Z' appears exhaustive
(indeed to record all process in a typical bank would require many dozens
of individual schemas). It is, however very precise in describing the
behaviour of objects in the system being specified.
'nuf said.
E-R Diagrams
Entities are rectangles,
relationships are diamonds, attributes are ellipses, KEYS are underlined.
Advantage: slightly
intuitive, fairly easy to draw
Disadvantages :
table design trial and error, many types of constraints are unable to
be specified, lack of referential integrity, lack of inter-fact type
constraints. Relies on clear differentiation between entities and roles
(which presents a problem as sometimes a role becomes an entity as in
the case of a nested fact type)
.....fin conceptual
modelling (yay!)
