Stateful constraints in TTM

#11 · August 2, 2019, 6:16 pm

Quote from Darren Duncan on August 2, 2019, 4:36 am

John, your example is absolutely no trouble at all. Anything you can express with words, if logically self-consistent, can be expressed as a single static constraint on the entire database.

You remind me of the mathematician who was asked to explain how to boil water on an (old-style) stove. His instructions began "Strike a match .... " Then he was asked how he would change his answer if the match had already been lit. He replied "Blow it out, then, and you have reduced the problem to the previous problem."

The best kind of database schema is one whose canonical relvars are self-auditing log-like insert-only.

Possibly. But that wasn't reas0nable for $EMPLOYER, who was far more concerned about the expense of disk storage and tape backup than about tracking the history of every department, team, and work group that had ever existed.

The records all represent immutable statements describing events or states of entities at particular points in time or within a sequence. The records do not represent mutable statements describing current states only. As such, anything can be defined as a single static constraint on the entire database.

Banks do maintain their data this way; google "bitemporality" if you're not familiar with it. But in a situaton where almost all queries are about the permanent state, and history is bunk, it greatly complicates writing queries.

#12 · August 2, 2019, 6:43 pm

Quote from johnwcowan on August 2, 2019, 6:43 pm

Quote from AntC on August 2, 2019, 4:40 am

Hmm? It's rule 1 that says that. Rule 3 says that a department tuple must be deleted under certain circumstances.

Yes, I renumbered my rules and became inconsistent.

In practice it would be daft to delete a department record (or any referenced-to datum) after it has been referenced-to.

I didn't write the spec and certainly don't claim to be a business analyst, with or without caps. The spec inventor wasn't one either.

Of course you can make up some business rule contrary to that, for the sake of perversity.

I don't think it was perverse, just not foreseeing all the consequences. But it was easy with the tech of that day: when you delete an employee, see if it's time to delete the department too. (This was not a relational database; I forget what it was.)

Was this a "classic employee-department database" as it said on the tin? Was this a database used for running payroll/allocating budgets/maintaining employment records?

No, that would be totally out of my scope. I forget the exact use of this system; I think it had to do with accounting for computer time or other such technical resources with funny money. And it did include groups more ephemeral than full-fledged departments.

Or was this in fact not a classic Department, but some sort of employee grouping/reporting unofficial not-really-a database?

Unofficial certainly: no accountant or auditor would be likely to look at it. But not therefore "not a database", and not without a business purpose, even if the details have faded after nearly forty years.

I'm inclined to agree with David B this is some "spurious set of constraints". There's a lot of questions of this nature on StackOverflow ('How do I design a schema for this?') from junior programmers who are not Business Analysts, and don't know the whole business context, and likely are trying to serve some under-the-counter reporting request from a business user who also doesn't understand the context. A professional's role is to a) refer the user to somebody who does know the context, not try to answer it themselves; b) if in fact it is the BA's design, to advise of the dumbness of deleting referenced-to datums after they've been referenced.

I agree with that — now. It was a pretty wild and woolly world, with a sharp divide between "mainframe systems" (very official, very inflexible) and "minicomputer systems" (not so official, but still important to the business, and very much "do what the customer says he wants", see below), and I was on the latter side. The introduction of PCs to work desks postfigured this same divide.

(I did draw the ethical/professional line earlier at working on a system for expenses management which recorded the discount received for various resources from the company's suppliers and then billed their customers for part of that discount. The general attitude was "Why should the customer keep all the discounts? We negotiate them." My reply was: "Fine, but then make it a fee of some sort. Don't report what are essentially padded expenses, money you didn't actually spend. You wouldn't tolerate that from your own employees."

(I didn't have to work on the system (some other poor fool did) and I wasn't fired. But the company was heavily fined for misconduct by New York State a few years later, and eventually collapsed completely when an employee was found to have faked huge profits instead of the large losses he actually took by exploiting a flaw in their (official) computer systems — long after I had left.)

Anyhow, I made my point (not all constraints are atemporal, to which I would now add "except in a system inherently (bi)temporal") and was pointed to a VSS (I've paid much less attention to those than to the Pres and Pros, not being a would-be D developer), so that's all I wanted.

Quote from AntC on August 2, 2019, 4:40 am

Hmm? It's rule 1 that says that. Rule 3 says that a department tuple must be deleted under certain circumstances.

Yes, I renumbered my rules and became inconsistent.

In practice it would be daft to delete a department record (or any referenced-to datum) after it has been referenced-to.

I didn't write the spec and certainly don't claim to be a business analyst, with or without caps. The spec inventor wasn't one either.

Of course you can make up some business rule contrary to that, for the sake of perversity.

I don't think it was perverse, just not foreseeing all the consequences. But it was easy with the tech of that day: when you delete an employee, see if it's time to delete the department too. (This was not a relational database; I forget what it was.)

Was this a "classic employee-department database" as it said on the tin? Was this a database used for running payroll/allocating budgets/maintaining employment records?

No, that would be totally out of my scope. I forget the exact use of this system; I think it had to do with accounting for computer time or other such technical resources with funny money. And it did include groups more ephemeral than full-fledged departments.

Or was this in fact not a classic Department, but some sort of employee grouping/reporting unofficial not-really-a database?

Unofficial certainly: no accountant or auditor would be likely to look at it. But not therefore "not a database", and not without a business purpose, even if the details have faded after nearly forty years.

I'm inclined to agree with David B this is some "spurious set of constraints". There's a lot of questions of this nature on StackOverflow ('How do I design a schema for this?') from junior programmers who are not Business Analysts, and don't know the whole business context, and likely are trying to serve some under-the-counter reporting request from a business user who also doesn't understand the context. A professional's role is to a) refer the user to somebody who does know the context, not try to answer it themselves; b) if in fact it is the BA's design, to advise of the dumbness of deleting referenced-to datums after they've been referenced.

I agree with that — now. It was a pretty wild and woolly world, with a sharp divide between "mainframe systems" (very official, very inflexible) and "minicomputer systems" (not so official, but still important to the business, and very much "do what the customer says he wants", see below), and I was on the latter side. The introduction of PCs to work desks postfigured this same divide.

(I did draw the ethical/professional line earlier at working on a system for expenses management which recorded the discount received for various resources from the company's suppliers and then billed their customers for part of that discount. The general attitude was "Why should the customer keep all the discounts? We negotiate them." My reply was: "Fine, but then make it a fee of some sort. Don't report what are essentially padded expenses, money you didn't actually spend. You wouldn't tolerate that from your own employees."

(I didn't have to work on the system (some other poor fool did) and I wasn't fired. But the company was heavily fined for misconduct by New York State a few years later, and eventually collapsed completely when an employee was found to have faked huge profits instead of the large losses he actually took by exploiting a flaw in their (official) computer systems — long after I had left.)

Anyhow, I made my point (not all constraints are atemporal, to which I would now add "except in a system inherently (bi)temporal") and was pointed to a VSS (I've paid much less attention to those than to the Pres and Pros, not being a would-be D developer), so that's all I wanted.

#13 · August 3, 2019, 6:26 am

You seem to have pretty effectively refuted the claim of plausible use case all on your own.

Plausible only if the IT department is derelicting its duties as data stewards for the enterprise's information assets; within an enterprise culture whose management is derelicting its duties as guardians of the owners'/shareholders' investment.

to which I would now add "except in a system inherently (bi)temporal"

I think the point of Erwin's message (and I wouldn't disagree) is that all business contexts are inherently bitemporal. BAs might take shortcuts (although surely today no-one would worry about scare-quotes 'wasting' storage space or index entries?) and design systems that ignore the temporality. Almost certainly it'll end in tears.

#14 · August 4, 2019, 2:29 am

Quote from AntC on August 3, 2019, 6:26 am

Plausible only if the IT department is derelicting its duties as data stewards for the enterprise's information assets; within an enterprise culture whose management is derelicting its duties as guardians of the owners'/shareholders' investment.

As I already implied, I had nothing to do with "the IT department" in those days (or these days), and if I remember correctly, payroll and such were already outsourced to ADP. And the things I dealt with were not "enterprise information assets": they were ephemera in the big picture: easy come, easy go.

I think the point of Erwin's message (and I wouldn't disagree) is that all business contexts are inherently bitemporal. BAs might take shortcuts (although surely today no-one would worry about scare-quotes 'wasting' storage space or index entries?) and design systems that ignore the temporality.

Doubtless they are. But in four decades working for startups and startup-y parts of bigger companies, I have uniformly found that the business doesn't care. They don't want the complexity of bitemporality, they don't want the added cost, and they don't care if it's all going to go wrong eventually — the leak won't be at their end of the boat.

Almost certainly it'll end in tears.

The fate of all companies is bankruptcy or absorption, as the fate of all individuals is death. This is, after all, a vale of tears.

TTM Forum

The Forum for Discussion about The Third Manifesto and Related Matters