The Need for Database Intelligence Software

  • TomThomson (7/15/2016)

    liver.larson (7/8/2016)

    I think this a pretty fantastic vision, really. It's easy to get caught up in the practical challenges of what it would take to even take a meaningful step in that direction, but it's a great concept.

    "Fantastic" strikes me as the right word! I don't believe that it's feasible to have database intelligence software that can decide what constraints need to exist without first being told about the business logic that determines data integrity. The creator of the database will have to have some means of describing that logic to the AI, and that will not be much removed from specifying constraints. Similarly, type information deduced from an early set of data requires that the early set is genuinely big enough to ensure that the chosen type is correct, and generating such a dataset is probably only possible by first understanding what type of data will in in what column in each table, and since the creator needs to have the type information to generate the data set he might as well just tell the software which types to use.

    I can't help but think of when cars were first built, the idea of anti-lock brakes was not even technologically feasible. When the technology began to make it possible, people reared back, saying "I know when to let off the brakes when I start sliding! As a driver of a car, that's part of the knowledge that I must posess!" But eventually, the technology made it's way into every car out there, and now it just happens automatically, and works well, whether or not you're a "good" driver.

    I don't think that's a good analogy for schema design; some things can be automated - index creation and deletion, which statistics should be generated how often and from what sort of data sample, recovery plan creation and validation that restore is possible re all things that can probably be automated (but the system has to be told what risk levels are allowable for which data and what performance levels are required for the various workloads so again it can't just happen by magic) - but feeding in the information required for chema design is non-trivial, even if one does it on the level of describing a single supertable with column type descriptions and a set of functional dependencies, a set of multivalued dependencies, and a set of join dependencies so that the software can convert the supertable into a set of tables and constraints conforming to 6NF (or should it only go to 5NF? or 4NF? or EKNF?) which is probably the only way (short of specifying all the tables and all the constraints) to describe the required business logic that determines data integrity.



    .... There will be challenges, yes. There will be bumps in the road, yes. It will take time, yes. But this is a fantastic vision, and it takes this kind of vision in the face of it being so impractical in the present, to drive the technology (and the culture surrounding it) forward.

    I like it.

    I think it's overambitious, too close to a sentient AI concept; but a lot of it will happn, although human input to tell this software what to do will continue to be required until we have genuinely sentient AIs (and that may never happen).

    You're actually touching upon building out an entity-based ontology. As you pointed the object at rest doesn't give you a lot of hints as to what its purpose it: what it intends to convey, how to talk to it, what language it understands, what kinds of things could it tell you, etc......

    Without knowing its purpose, you really can't infer a whole lot of anything.

    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Viewing post 16 (of 15 total)

You must be logged in to reply to this topic. Login to reply