DB layout is as follows:

--------------------------------
1
-------------------------------
1
---------------------------------
---------------------------
---------------------------
1 1
-------------------------------- |
1 |
-------------------------------- |
--------------------------------

Every client has a spreadsheet that must implement a version of Spec.
For this version, the cell config must corresponding to cells in the
spreadsheet containing fields for the given Spec.

As long a Cell Config references a Fileld, th DB will be happy, but
the problem I have is making sure that the Fields referenced by Cell
Config are indeed children of the Spec referenced by Spreadsheet
Config.

Is it possible to enforce this at a DB level? Maybe my model is
flawed?

Thanks

"dutone" <dutone (AT) hotmail (DOT) com> wrote

In principle it is possible, assuming your DBMS supports something like
SQL's CREATE ASSERTION statement for example.

--
David Portas

On 15 oct, 22:13, dutone <dut... (AT) hotmail (DOT) com> wrote:
In *no case* presentation should determine design. Proper design
should be the consequence of studying sound principles of relational
modeling.

For more info...

Introduction to Database Systems. CJ Date

Huh, who said anything about presentation? I'm trying to construct an
appropriate data model based on a set of business rules.
Thanks for the advice....

On Oct 15, 2:00 pm, "David Portas"
<REMOVE_BEFORE_REPLYING_dpor... (AT) acm (DOT) org> wrote:
I'd like to enforce this based on the data model and its
relationships.
Although to me, it doesn't seem possible without an additional layer
of logic.
The need for a check assertion in a RDMS tells me that cerain
cituations must be enforced at a higher level. This is one of them I
guess.

Thanks

On 15 Oct, 22:59, dutone <dut... (AT) hotmail (DOT) com> wrote:
Maybe your definition of a data model differs from mine. All such
constraints are surely part of that model irrespective of what syntax
the DBMS uses.

If you have some particular DBMS in mind then maybe someone will have
other suggestions about features supported by that product. Perhaps a
redesign would also be possible but I'm reluctant to begin a design-by-
newsgroup exercise.

--
David Portas

"David Portas" <REMOVE_BEFORE_REPLYING_dportas (AT) acm (DOT) org> wrote

analysis.

Second, "enforcing this based on the model" is clearly an implementation
issue, not a modeling issue.

On Oct 15, 3:54 pm, dutone <dut... (AT) hotmail (DOT) com> wrote:
"client", "spreadsheet", "cells", etc. all sound like user interface
or
presentation concepts. Difficult to tell without working definitions
for these entities that you have identified, though.

"dutone" <dutone (AT) hotmail (DOT) com> wrote

Where you say data model I am sure you mean "logical model" or "conceptual
model". Although most people would understand what you mean when you use
that term, it is a colloquailism that can/will be misconstrued by readers of
this newsgroup. More importantly, if you do take the advice you will get
about reading books on fundamentals you will find it easier if you know
those books use the term data model for something very different than you
expect.

I suspect you might be thinking that referential integrity constraints
should be enough to represent the business rules of your entire enterprise
of interest. That is not possible even in principle. There are all kinds
of other constraints that one needs, and SQL is supposed to implement some
of them (e.g. the check constraints you refer to, and general
constraints/assertions). Whether your SQL implementation provides them is
another matter, but in any case SQL doesn't provide all the constraint
mechanisms you could want, and if it does it may not support them flexibly
enough (e.g. by allowing checking to be deferred).

In practice you will have to enforce some assertions in your application,
but only because your SQL server doesn't. You should take advantage of
whatever limited constraint enforcement your SQL implementation provides,
for a whole lot of reasons.

Roy

On Oct 16, 7:03 am, David Portas
<REMOVE_BEFORE_REPLYING_dpor... (AT) acm (DOT) org> wrote:
I'm not trying to start a group design effort, but his original model
certainly seems to me to have the Cell Config in the wrong place. At
the logical lege, the connections should be described verbally (the
cardinality can be there but blank connections between entities leaves
too many unidentified assumptions.

So many business systems designers unconsciously think everything
about their application is "intuitively obvious" when the truth it, it
is not obvious, sometimes not even to the initiated.

Ed