This is about the allocation of program resources, and distributed design
techniques. Mongo Santa Maria played the entire piece on the bongos at the
Village Vanguard on Wednesday. You shoulda all been there. Head
CodeHead,
and iPils whare were you . ? I am still working on the applicaton
developer
course for my new baccalaureate degree from U. C. Samta Barbaera buth they
cut the funding for our sailboat classroom. I may transfer to a college
with
sailboat.
Welcome your ideas for oceanographic mapping institutes or merchant
shipping
academies included.
I suggest following up with the data modeling study mentioned as a prelude
to the addition of distributed data to a distributed project model. And
although all the problems are not worked through, I thought this paper had
some minor contrbution to add to a discussion of structure and timing of
systems inclding language IDEs). bongo rock intro curtain...
Application Architectures
This section is from chapter 2 of the reference book in Advanced
PowerBuilder 4 Techniques, pp. 6 which describes high-level concepts used
to
develop an application. The blueprint for the application is known as the
system architecture. This blueprint can be for a one-tier, two-tier, or
three-tier system. The architect should understand the prevailing
standards
when designing an architecture for a application. The author mentions
OOD,
RPC, X.400, MAPI and CORBA as some prevailing standards. Standards will
assist the application architect when designing the system architecture
(blueprint). The most important foundation for the application is the
requirement list of the user or client.
Then the framework or direction of the architecture can be determined.
These terms relate to the requirements that can affect a system
architecture
(blueprint). Performance, maintenance, data distribution and scaleability
are some of the many customer requirements that can affect a system's
architecture.
A good application architecture will benefit the developer in terms of
time
requirements, reuseable components across other applications,scaleability,
ease of maintenance, and better application performance.
An application architecture (blueprint) is more justified when the
application design will be one of several, and will provide the ability to
meet future scalability and needs of software customers. And the result
of
an application architecture (blueprint) will simplify software development
in avoidance of a need for duplicate testing, and duplicate documentation
writing. Referring to a use of shared objects and how to set up a
development architecture to maximize their use, as given earlier, Advanced
PowerBuilder 4 Techniques, pp. 27 the common objects can be designed for
visual, business and service objects. The application architecture
(blueprint) is developed to integrate the visual GUI and the class
libraries
which can be common to a number of applications.
The section of Chapter 2 will cover the following application architecture
issues:
Tiered Architectures pp. 7
Two-tier Architecture
A client/server architecture in which the cliets perform the
presentation
functions, and
a database server performs te database functions. In a fat client
configuration, the clients
perform the business functions, whereas in a thin client configuration,
the database server
performs the business functions. "Concepts of Database Management",
Glossary pp . 410
Three-tier Architecture
Services Architecture pp. 11
eMail
An eMail Service Architecture
Other Services pp. 15
Data Access
Print
OLE
DDE
Clipboard
Security
Modem
Drag-and-Drop
Fax
DOS/File I/O
Multimedia
EDI
PowerBuilder Object Orientation
Inheritance - pp. 18
Advantages of Inheritance
Disadvantages of Inheritance
Inheritance in PowerBuilder
Design Considerations
Encapsulation - pp.22
Encapsulaton in PowerBuilder
Design Considerations
Polymorphism - pp. 23
Overloading
Overriding
Polymorphism in PowerBuilder
Design Considerations
Binding - pp. 25
Design Considerations
PowerBuilder Class Libraries pp. 26
Sharing PowerBuilder Objects
Sharing PowerBuilder Objects
An application should include a library to store shared objects. All
types
of PowerBuilder objects can and should be shared among developers of one
application or many applications.
Object sharing begins with the definition of an object class hierarchy. A
class hierarchy can be defined for windows, user objects, and menus.
However object sharing extends beyond these objects to other objects such
as
DataWindows, functions,. structures, and SQL. A note that Superbase 95
provides the diagram of its object hierarchy model.
Through the course of application design and development, it usually
becomes
clear that different functions in an application will have some
overlapping
components Advanced PowerBuilder 4 Techniques, pp. 30. An example of this
would be where both query and a report which require a connection to a
database. And the code required to set up the PowerBuilder transaction
object and handle communication with the database is similar in both
cases,
and can be shared by both functions.
Generic code can provide functionality common to many application
functions,
as in the case of loop structures, control statements etc.
One of the most valuable benefits of object-oriented development is this
ability to share objects. A correctly built PowerBuilder application uses
the power of inheritace to minimize coding and to maximize efficiency.
Then
sharing objects increases code reliability and interface consistency and
eases the task of code maintenance by reducing or eliminating the need for
duplicate code.
Objects in Context
Windows, user objects, and menus can share functionality. For these
objects
functonality should be built into a set of virtual classes from which
application objects can be derived.
DataWindows can be shared by encapsulating them within a user object.
Using user objects allows the virtual classes of DataWindow controls to be
defined and implemented in the same way as other object hierarchies.
Only necessary attributes and information handling routines can be placed
into the system. They should also be properly related. A properly
integrated system stores the data and the data manipulation procedures
together.
A reference book on Nomalization can be used to study relations.
The objective in the object modeling process is the system applicaton
which
is being created. We are creating a material application which accepts
inputs and processes and shares internal or external data and information.
However as we press on, we should separate the development function from
the
material result which we are working toward. Our development program is a
flexible program and we can establish its purpose, and then we can reset
its purpose for the development of a new facet of the application which we
are developing. We can reset its internal parameters as we may care to.
We
can use it to guide the activity of a staff and participants.
The development program is working with the representation of the real
world, which is how data represents the real world, through representation
in a standard unit. A mile in distance can be represented in a computer
program by using a scale of distance i.e., 5,280 ft. = 1 mi. The
participants in the development program can obtain the data file and the
data manipulation routines, while they may not have such access to the
real
implementation of the application being developed (as users).
The use of brainstorming sessions during early stages of the appliation
development is useful as a way to communicate a potential goal for the
application. The items which can be interesting to discuss will be either
tangible or abstract, representing ideas which reside with the development
phase.
Tangible objects would be i.e., workers, equipment, development programs,
participants, and other things to keep track of.
Examples of more abstract objects would be, i.e., purchase invoices,
registration cards, organizational units, physical locations, data about
people or things or events that the system must remember.
The borderline between what is tangible and what is abstract is not always
clear. On one hand, if we need to keep track of papers and secretarial
workers where invoice information is written and stored, it is tangible
informtion. But if we are interested in the information written on the
invoice it is a model component, more abstract than tangible.
Object Modeling and Concepts from the Abstract
In models we are faced with the complexity which results from having to be
aware of many details at the same time. Modeling therefore presents the
means of handling complexity. And to assist us with the handling of
complexity we have to structure the information we are putting into the
model.
A high-quality model fills the same function as a summary. A poor quality
model is like a confusing report which states every conceivable fact.
We should restrict the list of items which we present to those which are
most relevant, and fewer in number in order to keep the summary to a size
which we can comprehend. And it is useful to form groups among the
diverse
enties in our model. A mention on this was described with user objects,
above. Groups of objects can share functionality through menus, network,
development of procedures, etc.
We should hide needed information details in the background whenever
possible.
Steve Roman wrote Access Database, Design and Programming by Steven Roman
publ. 1997, and focuses upon designing a database. The task of defining a
database involves the process of decomposing data into multiple tables
(Roman pp. xiii Preface). He writes that you can create a database object
using VBA code in Excel. And this leads to the consideration of the
entirety of Excel VBA programming.
Our reference book, Microsoft Excel VBA Programming for the Absolute
Beginner by Duane Birnbaum includes the contents:
Visual Basic for Applications with Excel Chapter 1 pp. 1
Beginning Programs with VBA Chapter 2 pp. 21
Procedures and Conditions Chapter 3 pp. 51
Loops and Arrays Chapter 4 pp. 87
Basic Excel Objects Chapter 5 pp. 133
Enhancing VBA Programs: Adding Multimedia and Intelligence Chapter 6
pp.
187
UserForms and Additional Controls Chapter 7 pp. 227
Data Access, File I/O, Error Handling, and Debugging Chapter 8 pp. 269
Excel Charts Chapter 9 pp. 313
VBA Shapes Chapter 10 pp. 357
Index pp. 397
The Top Level Excel Objects (Chapter 5 VBA and OOP)
The Application Object Chapter 5 pp. 145
Workbook an Window Objects Chapter 5 pp. 145
The Worksheet Object Chapter 5 pp. 153
The Range Object Chapter 5 pp. 154
Working with Objects Chapter 5 pp. 157
Data Access, File I/O, Error Handling, and Debugging (Chapter 8 File I/O)
File Input and Output I/O
Using VBA File I/O Methods
Error Handling
Debugging
In the listings of topics above, refer to the design or programming for
operating system objects in many cases. But we have to structure the
information which we enter into those objects to create an orderly
aggregation which includes relevant groupings. The design of a program
should lend itself to the task of handling complexity, in the same way
that
a summary report presents a summary of current information about a
business
function (accounts, inventory, payroll, etc).
Windows was designed to be at the heart of an application development
system
which could interact with many types of external devices i.e., network
cards, hard disks, printers, and data entry readers. The Windows
operating
system changed the personal computer environment by working with the
development of standards and designing improvements such as a virtual
memory
table that expanded the total amount of memory, through shared memory
tables
made available to programs by the Windows operating system..
In a certain way, the application programs we could write have to be
designed independently of a development environment such as Visual FoxPro
6.0 or PowerBuilder. The Microsoft corporation also offers its own
application development solutions. Microsoft Visual Studio 6.0 (include
Visual FoxPro 6.0) is a development system for Windows and the Internet.
A
development studio can be used effectively to reduce the amounts of raw
program code that needs to be written, while it also enables some program
components (both those produced at Microsoft, and your own components) to
be
shared between applications. But to become a developer, I found that it
is
necessary to have a background in application design, which is mostly a
problem solving issue. If you as a developer do not know four or five
types
of inventory management systems, then none of these development tools is
going to be a useful tool, for developing an inventory management system
which meets all of the requirements of the warehouse inventory structure.
I
am sggesting tat certain tradeoffs will probably have to be considered to
be
a minimum for a good application design and implementation.
The sales of software do not seem to be tied to the knowledge requirements
of application software development, and it seems like a good hobby to
try,
but benefits from application software will not be increased by the sale
of
the developer tools any more than the sale of jet planes will directly
increase the number of good pilots.
The use of application development tools would be a portion of a
communication effort among a group of programmers. The application
deveopment tools would provide useful templates that assist the goal of
uniformity throughout parts of the development system. Generic code can
provide functionality common to many application functions, as in the case
of loop structures, control statements etc.
One of the most valuable benefits of object-oriented development is this
ability to share objects. A correctly built PowerBuilder application uses
the power of inheritace to minimize coding and to maximize efficiency.
Then
sharing objects increases code reliability and interface consistency and
eases the task of code maintenance by reducing or eliminating the need for
duplicate code.
The most important foundation for the application is the requirement list
of
the user or client.
Program Documentation
Documentation of the program project is a major trade-off that must be
made
when writing software applications for a system environment. A reference
book An Introduction to Data Structures by John Beidler (Univ. of
Scranton)
publ. Allyn and Bacon, Inc. 1982 pp. 5 "The most sophisticated program can
be almost worthless if it is not documented in such a way that others can
read and understand how the program functions. It is important to
remember
that programs must be read by humans as well as by computers. In fact,
the
biggest problems faced in software development is the modification of
programs." .. "A good measure of a well written program is this: A program
by its very existence changes its environment. It can provide new
information which in turn suggests further enhancements to the program.
If
a program can be easily modified so that it can be changed to keep abreast
of its changing environment it is one of the best tests of the quality of
the original design of the program."
"One consideration which programmers must take into account during the
design of the program and implementation is the programmer's personal
resources. These include the human time which it takes to perform the
programming process, in addition to the computer time and the computers
required to encode, debug
and carry out the program. ... Yet speed or program efficency should not
be
used as excuses for writing programs that cannot be maintained, are
unreadable, or lack documentation, testing, etc..
Program Measurement
An important part of simplifying the internal program design is separating
the physical details of how certain things are carried out from the
logical
requirements of what is supposed to be accomplished. Once a program
exists, new questions arise. In particular, how well does a program use
its
resources? What are the program's time and space requirements? Does the
program make efficient use of its resources? Which variables influence
the
program's resources? Wht effects do these variables have upon the program
resources?
A space requirement refers to the internal memory and disk drive storage
space that is necessary to use the program. This is a requirment which is
the sum of the space for the program and the data space. The space
requirements for the program itself are related to a specific computer
system.; Normally a program is written to function within agiven
hardware/software environment.
A time requirement means the amount of time used by a program. This can
be
thought of in relation to the central processor, the amout of "wall time"
that is time measured by the clock on your wall, I/O time, etc.
The time and space required by a program depend upon:
- the actual hardware
- the algorithmic structure of the program
- the data processed by the program
With regard to the structure of algorithms, there are four considerations,
the three basic control constructs, and modularization, specifically:
1- sequencing of program steps (control construct)
2- loop control (control construct)
3- conditional code execution (control construct)
4- modularization (modularization)
Sequencing is the sum of the time for the individual steps in the
sequence.
Loop control time depends upon the number of times when the loop must
execute, plus the hardware time involved
Conditonal execution relates to a particular section, or a group of
sections
which will be executed. The execution time amounts to the time of each
sequence plus the hardware time of each sequence. see An Introduction to
Data Structures by John Beidler (Univ. of Scranton) pp. 17.
Time constraints are important where it comes to meeting the internal
schedule of the program execution. In some scenarios a particular step
can
be allowed to time-out and the program execution resumes. Beidlr provids
a
notation which can be used to evaluate the time required to determine the
execution time for a program pp. 19-21. It involves the total of the time
required for sequencing, looping, and sections which are conditional, in
addition to subprograms and conditonal controls (which might include units
of time).
He adds that the data being processed can affect the time and spce
requirements o the program. He considers three items:
1- The amount of data
2- The actual values of the data items
3- The organizaton of the data (is it ready for an orderly processor)
Amount of data affects the linear measure of time (how long) in tems of
reading the data.
Actual data values refers to an algorithm which is applied to the data or
the size of the numbers themselves. A multiplication by zero (0) will
take
less time then, 3456 times 233. A complex loop wll take longer.
The organization of data suggests how the data will be entered. Tape
drives
are slower devices and take longer etc.
Beidler suggests pp. 22 finding a bound on the program execution time or
the
most important variable of the timing equation. The focus upon how the
program time changes as that variable gets larger. Using the structure of
the program and assumingthat any sequence of instructions is bound by some
constant K, the timing result is based upon the number of these sequences.
A collection of counting methods can be used to approach the program
timing
issue, by building prototypes that execute commonly used steps and
iterations. The loops can be counted (number of executions) using
incrementing counting variable every 100 iterations perhaps Beidler pp.
25.
And for sub loops they set up a MIN and MAX which will be averaged, and
added to the program time in proportion to terms of the conditional
execution.
Overall, the program timing depends upon the time of execution required by
any sub programs, plus the requirements for a main program section. Some
portions of time can be fixed by a standard unit time delay.
Some Logical Structures
This section is from reference book An Introduction to Data Structures by
John Beidler (Univ. of Scranton) Chapter 3 pp. 37. "This chapter
represents
an intuitive description of several of the structures that are studied
(throughout). Actually most of thesestructures can be represented in many
ways, and the problem ofchoosing a structure and its apropriate
representation is really two distinct problems:
1- Selecting the appropriate structures to represent and solve a problem
2- Selecting the appropriate representation of the structure to fit into
the
problem's solution and resources.
The structure of a problem and the structures that lead to an efficient
solution can sometime defy the clarity needed to understand them. A
structure in a software program or in data, refers to both a real
structure
(in the computer) and the applied structure, how it is used. When asked
to
state the structure of a building, a college, or a corporation the issues
are presented from observers points of view. The applied structure, how
it
is used becomes one of access and utilization. see An Introduction to
Data
Structures by John Beidler (Univ. of Scranton) pp.2.
"As essential data structure techniques are attempted, the importance
of
good programming practices become more apparent. In particular, by
carefully studying the logical requirements of a program, and working out
the logical requirements before generating the code, many potential
difficulties will be bypassed. If more time is spent understanding a
program
and designing the logical requirements of an algorithm, then less time
will
be spent patching and debugging an inapproproate program."
The book An Introduction to Data Structures by John Beidler (Univ. of
Scranton) proceeds to chapter 2 where a discussion about program
measurement is developed. "BAsically, given a computer system, a program
has two resources, time and space, whse usage is affected by three factors
-
(1) hardware, (2) the algorithm, and (3) the data...
Structured programmingassists the programmer with the question on how well
does a program use its resources?. Which variables influence the
program's
resources. The section considers the effects of the algorithm, and the
data
upon the program's timing. Hardware is considered but I see the hardware
as
being beyond what I can worry about.
There is no complete and exhaustive collection of program measurement
techniques. Program measurement can be difficult and sometimes
impossible.
Basic techniques of measuring a program's time requirement and methods of
recognizing certan recurring timing situations are available. Space
requirments can be described using these techniques as well An
Introduction
to Data Structures by John Beidler (Univ. of Scranton) pp. 15.
Space and Time Measurement
This is a section on the delivery of a modular application which is
effective within the tradeoffs of informational dimensions i.e., user
documentation annd training, along with real world performance of the
purpose, and logical design issues for responsing to the feedback to the
system, and computer system craftwmen would be involved in this issue as
well.
I have a book titled Space-Time Information Processing by A. Winder and
Charles J. Loda publ. Peninsula Publishing Los Altos California circa.
1962
for Office of Naval Research a reprint was done in 1981 under the title
given. The original title was Introduction to Acoustical Space-time
Information Processing. That book begins with issues of stationarity vs.
ergodicity. Ergodicity would seem to involve energy and movement, where
stationarity is the negative of those. The introduction states that the
book is about multi-dimensional information processing involving radar,
and
pulses (sonar).
Linking Data Files
Data files are linked using referential attributes which make it possible
to
reference other objects. In a top-down structure, referential attributes
are used in sorting and associations between the data files of our model
(model world).
A reference Concepts of Database Management Fifth Ed. by Pratt and
Adamski
publ. Thomson Course Technology Boston 2005 pp. 197 offers the discussion
on
Top-Down versus Bottom-Up database design methodology. "Another way to
design a database is to use a bottom-up design methodology in which
specific
user requirements are synthesized into a design. The opposite of a
bottom-up design methodology is a top-down design methodology, which
begins
with a general database design that models the overall enterprise and that
repeatedly refines the model to achieve a design that supports all
necessary
applications."
The top-down approach lends a more global feel to the project; you at
least
have some idea where you are headed, which is not so with a strictly
bottom-up approach.
On the other hand a bottom-up approach provides a rigorous way of tackling
each separate requirement and ensuring that it will be met. In
particular,
tables are created to satisfy each user view or requirement precisely.
see
sections on developer groups above.
The ideal strategy combines the best of both approaches. Assuming that
the
design problem is sufficiently complicated to warrant the benefits of the
top-down approach, you could begin the design process for the database by
completing the following steps:
1. After gathering data on all user views, review them without attempting
to
create any tables. In other words, try to get a general feel for the task
at hand.
2. From this information determine the basic entities of interest to the
organization (sales reps, customers, orders, and parts). Do not be overly
concerned that you
might miss an entity. If you do it will show up in later steps of the
design methodology.
3. For each entity, start a table
4. Determine and list a primary key for each table.
5. For each one-to-many relationship that you can identify among these
entities, optionally create and document an appropriate foreign key.
Concepts of Database Management Fifth Ed. pp. 198.
After completing the steps, for a top-down-approach, you can apply the
methodology for examining individual user views. As you design each user
view, keep in mind the tables which you have created and their keys. When
you need to determine the primary key for a table, look for a primary key
in
the cumulative design. In either case, if the primary key already exists,
use the existing name as a foreign key to ensure that you can merge the
tables properly. pp. 198 ...
Reference Fields
A reference book Superbase Revealed! by Fred Dalgleish and Carolyn
Drakeley
publ. Prima Publishing, Rocklin California 1993 describes a use of
reference
numbers in three contexts:
reference numbers for fields pp. 100
reference numbers for OLE pp. 512, 522
reference numbers for records pp. 193
Referential attributes are used to access and view records in a database
file in a sequence based on a specific field's value in those records
Superbase Revealed! pp.99. A unique index is used to ensure that a
specific value for a field occurs only once in a database. These are
notions about data structure which amounts to an internal system used to
manage data, for speed and relational database features. The emphasis in
data structures is the presentation of many different ways of representing
information.
Superbase Revealed! Chapter 4 will discuss how index files are used for
record lookup purposes and particularly how the lookup function can be an
integral part of certain validaton and calculation rules to ensure the
field's vaules meet specific conditions.
Use of reference numbers for records in Superbase Revealed! Chapter 6 is
a
discussion about referring to a record by the value in a field, for the
purpose of a file update -delete of the unnecessary records by selecting
particular records using the value contained in a reference attribute
named
REFNumber.
Another use of a referential attribute is discussed Superbase Revealed!
Chapter 15 OLE andSuperbase. there are two parts to an OLE link or embed
using Superbase:
An external file field in the Superbase record holds a reference number to
th embedded object.
The actual object is stored in a file with the same name, but with the
extension *.SBO. the number in the external field points to an object
stored in this file.
Chapter 15 suggests looking up the OLE topic in Superbase manuals Creating
Databases pp. 181 Linking and Embedding Objects with OLE and DDE presents
Superbase as an OLE client (host). OLE and DDE make data from other
Windows
appliations immediately available in your Superbase database. Superbase
can
be a server only in DDE.
You can either embed an object that already exists in the server
application, or you can start up the server application within Superbase,
create a new object, then return to Superbase and embed the object.
Some Logical Structures
This is a section from An Introduction to Data Structures by John Beidler.
The title of chapter 3 Some Logical Structures highlights the intuitive
description of several of the structures that are studied throughout the
book. He does not suggest specific representations sincethese structures
can be represented in many ways. Choosing a data structure and its
appropriate representation is really two distinct problems:
1- Selecting the appropriate structures to represent and slove a problem.
2- Selecting the appropriate representation of the structure to fit into
the
problem's solution and resources.
When reading chapter 3, you should make observations about the
capabilities
and limitations of each structure. The examples illuistrate some of the
classical uses of the structures.
A table of contents entry for chapter 3 :
Sequential structures
Sequential structures with Very Limited Access
Graphs
Directed Graphs
Trees
Exercises
Som general ideas about modeling (representation) refer us to the issue of
handling complexity whih involves the awareness of many details at once.
The data structure is just one of the details involved in application
development. In a top-down design process these structures are used in
sorting and associations between the data files of our model. Th
structures
are a portion of the development model, rather than the functional
environment of the applicaton. We can develop of many applications
(subsystems also) which require data management, using these structures.
We
have to refer back to our purpose when we make a model, or implement these
models.
....
....
DatabaseDesign 1
Functional Dependence -
This book by Roman will discuss the basic concepts of relational database
theory and design. To accomplish this goal, Romans describes the how and
why of creating an efficient database system, explaining such concepts as:
Entities and entity classes
Keys, superkeys, and primary keys
One-to-one, One-to-many, and Many-to-many relationships
Referential integrity
Joins of various types (inner joins, outer joins, equi-joins, semi-joins,
0-joins, and so on)
Operations of the relational algebra (selection, projection, join, union,
intersection, and so on)
Normal forms and their importance
In this chapter see Concepts of Database Management by Pratt and Adamski
Fifth Ed. pp. 140, you will learn about two crucial concepts which are
fundamental to understanding the normalization process: functional
dependence and keys.
After mastering this material you will be ready to begin your study of the
database design process of chapter 6. Notice tables are outlined pp.
140-141.
Functional Dependence - is a formal name for what is basically a simple
idea.
Definition : A column (attribute) B is functionally dependent on another
column A (or possibly a collection of columns) if each value for A in the
database is associated with exactly one value of B.
You might say, see pp. 142
"A sales rep's pay class functionally determines his or her commisson
rate,"
or
"A sales rep's commission rate functionally depends on his or her pay
class."
You can think of functional dependence as follows: If you are given a
value
for A in the database, do you know that it will be associated with exactly
one value of B? If so, then B is functionally dependent on A (written A
->
B). If B is functionally dependent on A, then you can also say that A
functionally determines B.
You can not determine functional dependencies by depending upon a look at
the data pp. 143. The only way to determine the functional dependencies
that exist is to examine the user's policies through discussion with
users,
an examination of user documentation, and so on.
Keys and Superkeys
Keys -A second underlying concept of the normalization process is that of
the primary key. You already encountered thhe basic concept of the
primary
key in earlier chapters. see Concepts of Database Management by Pratt and
Adamski Fifth Ed. pp index.
Definition : Column A (or a collection of columns) is the primary key for
a
relation (table) R if:
Property 1 : All columns in R are functionally dependent on A.
Property 2 : No subcollection of the columns in A (assuming A is a
collection of columns and not just a single column) also has Property 1.
Remember that although all columns may functionally depend on a particular
combination (as a primary key), if one column (or another combination of
columns) would also meet the requirements of a primary key then neither of
them is a primary key. pp 146. see to Concepts of Database Management by
Pratt and Adamski Fifth Ed. pp. 145-146 for examples.
The concept of a superkey applies to entity classes, and not entity sets
(a
set of real items). A set of attributes see Access Database, Design and
Programming by Steven Roman pp. 13, that uniquely identifies any entity
(item) from among all possible entities in the entity class that may
appear
in the database is called a superkey for the entity class. Thus the set
{ISBN} is a superkey for the BOOKS entity class and the sets {PubID} and
{PubName, PubPhone} are both superkeys for the Publishers entity class.
Note our definition of the superkey is subjective because it depends
ultimately on our decision about which entities may ever appear in the
database, and this is probably something of which we cannot be absolutely
certain. There is an elaborate explanation to this question about keeping
the system from bogging down by entry of data which causes the dependence
relationships to become invalid. The particulars should be restated here
when they are located within another book.
One ofthe dfifficulties wth superkeys is that they may contain more
attributes than is absolutely necessary to identify any entity. And it is
more desirable to work with superkeys which do not have this property.
And a superkey with the property that, no proper subset of it is also a
superkey, is called a key.
Thus, a key is a superkey wth the property that if we remove an attribute,
the resulting set is no longer a superkey. A key is a minimal superkey
(with all the same attributes).
Candidate Keys
Sometimes keys are called candidate keys, since it is usually the case
that
we want to select one particular key to use a an identifier. We select
the
particular key we will use from among any of the candidate keys.
The particular key we choose ti use as a identifier is referred to as the
primary key.
The primary keys in the LIBRARY database are ISBN, AuID, and PubID.
BOOKS_______________________
ISBN Title Price
0-103-45678-9 Illiad $25.00
1-22-233700 Visual Basic $20.00
....
______________________________
A good discussion of the topics we have t workl on here is located in a
book
Relational Database Design Handbook, by Candace C. Fleming and Barbara von
Halle. Theri book is a handbood describing two full methodologies.
Part I - summarizes the knowledge required for the study of subsequent
chapters. It introduces the concepts and principles underlying the
design
methodologies.
Part II - contains the logical data modeling methodology. A step by step
procedure on building your logical data model.
Part III - presents the relational database design methodology.
Index of Design Rules - a summary of logical data modeling guidelines.
A Logical Data Model
Von Halle and Fleming, Chapter 2 Introduction to Logical Data Modeling pp.
9
Major Concepts of Logical Data Modeling pp. 12
Role of a Three-Schema Architecture pp.18
Step in Logical Data Modeling pp. 19
Critical Success Factors in Logical Data Modeling pp. 24
Benefits and Applicability of Logical Data Modeling pp. 27
Summary pp. 28
Logical Data Modeling (LDM) is a technique for clearly representing
business
information structures, in the database design process. LDM also involves
business rules which are also inputs in the database desig process.
Business data have an existence. Data represents something which exists.
The business data we implement using database software are a valuable
resource for a business organization. LDM is atechnique for recognizing
and
documenting te fact that business data have an existence independent of
how
they are accessed, who access them, and wether or not such access is
computerized.
By recognizing the existence of business issues (facts), identifying those
that are significant to a user's business, and developing a corresponding
logical data model, you are in a better position to accommodate access
requiements through database technology.
A LDM often can help people understand specifics of the business, even
when
they are not to become a part of a database implementation.
Some people pay bills on time
Some people do not pay bills on time examples of business facts
Some people eat ice cream cones
Characteristics of this methodology:
An entirely data driven process - represents types of information
(entities)
to be used in the business, without bias from implemntation or application
need
Encourages comprehensive understanding of business information
requirements
Enables effective communication among designers, developers, and users
throughout the design process
It forms the basis for designing correct, cnsistent, sharable, and
flexible
databases using any database technology available
The methodology is used to develop a a process for producing complete
documenation of information requirements.
Some issues in general are:
- What are the major information objects or concepts of interest to the
functional department function (i.e., accounting, inventory, customer
service)?
- What detail information items characterize those major information
objects
(customer name, customer ttelephone #, part number etc)?
- How are those major informatnon objects or concepts related (bills are
sent to customers requesting payment for ...)?
With the answers to inqueries such as above, we collect data-driven facts
which priovide an unbiased understandiong about how information is
employed
throughout the business.
We use LDM to model thie unbiased understanding of the business'
information
requirements, which provides a greater stability and flexibility within
subsequent database design whch will be based upon the LDM. see Von Halle
and Flemig pp. 10.
Access priorities will be an afterthought, which will have a full context
of
the LDM as a basis. Other technology-based constraints, and priorities
will
also be secondarty to the business data, in this methodology.
The resulting LDM is translatable, using any technology, to a database
design that is:
Correct - an accurate representatation ofthe way information is used in
the
business
Consistent - without contradictions in the way the information objects are
named, defined, related, and documented
Sharable - accessible by multiple applications (data sharing) and used to
meet varying access requirements
Flexible - facilitating additions to reflect new information requirements,
"tweaking" to accommodate strengths or weaknesses of an implmentation, and
business operations
This Von Halle and Fleming work, is a simplified version of a rigorous,
formal treatment. It will address the majority ofbusiness situations,
though not every situation.
A diagramming techniqe is used to graphically describe a LDM procedure.
And
it saves time thoriught the entire process of database implementation.
LDM
The most important constructs within an LDM are entities and
realtionships.
An entity is a person, place, thing, or concept about which you wish to
record facts.
|
