Re: What is analysis?

Quoth David Cressey:
> I don't think of "formal" as a code word for "scientific". In fact, I
> don't even think "engineering" is code for "scientific". Science is about
> discovery. Engineering is about invention. There is a lot of overlap in the
> language, the tools, the method and the mode of thought. But they aren't
> interchageable.

Yes, I was being sloppy. My (poor) defense is that the Norwegian word for science ("vitenskap") is used rather more broadly than the English term.

> And I'll accept that information systems evolve along with changing
> requirements. But
> I'll also claim that some good analysis can accomplish in weeks when take
> months worth of iterative development.

Yes, but despite my nifty definition, I still have a hard time separating analysis and design/development. I find it very difficult to imagine one without the other.

> It would be interesting to know if there is a way of deriving relvars from
> some form of data analysis that doesn't involve ER. I am convinced that a
> set of relvars embeds design decisions, but I don't know from direct
> experience. What do you say?

Well, what do you mean by "design decisions"? Relvars and constraints (including, but not limited to, keys and foreign keys) represent business rules. A specification of business rules seems like a natural product of analysis to me. Of course, you could start with the business rules and go to relvars from there. Or use ORM (in my opinion, ORM is quite different from E/R), but the end product of ORM analysis (I know, it's not just a diagramming notation ("boxology"), but a method(ology)) is no more and no less than a set of relvars and domains with possreps. This might (or might not) be troublesome if I were to implement a database with a non-relational tool, but fortunately, I've never had to.

I'd say a relvar specification (which may take the form of an ORM diagram, or prose predicates) is an excellent goal for data analysis. That it is very simple to implement in the relational model is a strength of RM, not a weakness of the spec.

>> I don't consider foreign keys all that special. It always annoys me when
>> someone says that foreign keys signify relationships. They don't; they
>> /constrain/ relationships. Relationships are given by attributes being
>> defined over the same domain (although this makes far more sense if your
>> DBMS has proper domain support). Anyway, I don't feel the need to talk
>> much about foreign keys. I talk about identifiers (key constraints), and
>> say that this column/attribute is the same as that.

Yes, that sounds better. I still say it's wrong, though.

-- 
Jon