When databases were sized in megabytes rather than petabytes, their design was a well-defined discipline of data analysis and implementation. A progression of modeling steps – from conceptual and logical through relational and/or physical – promised successful deployment.But as we passed more orders of magnitude in data volume, we seemed to stop seeking modeling approaches to manage that volume. So the question arises: Is logical data modeling obsolete?To arrive at a reasonable answer, we’ll have to recover some forgotten lore about data modeling.
This is the fourth in our multi–part series on data modeling for information security as well as data characteristics. A simple data model for a fictional website that supports shared–interest organizations (bird–watching clubs, etc.) has provided us with content for exploring data modeling from a security viewpoint.In Oscar Wilde’s playLady Windermere’s Fan, Lord Darlington tags a cynic as “somebody who knows the price of everything, and the value of nothing.” Sadly, the information in our databases can be unconsciously treated in the same way. Is a customer account worth the sum of its purchases? What do we suffer if we lose four hours of marketing data during holiday shopping season?
This is the third of our multi-part series on applying information security approaches to data modeling. The series uses a simple data model, something to manage social clubs and interest groups, to provide the content we look to secure. Later we will address modeling for authorization and user management, as well as other parts of a secure database implementation.In social situations, it’s common to “read between the lines” – deducing the unspoken assumptions and assertions in a conversation. The same occurs in creating software and storing data in a database. Invoices are enumerated with the customer ID embedded, and how many data entities use a date-time as part of the key? It’s hard to imagine thoroughly documenting or structuring everything without some type of omission. But in our last instalment, we went through exactly that exercise. We were able to ascribe sensitivity to several parts of our social club database. But to quantify and manage that sensitivity, we must augment the structure of our data model in order to make the sensitive data and its relationships clear.
Early in the movie “The Fellowship of the Ring”, the wizard Gandalf asks the hero Frodo this question:“Is it secret? Is it safe?”We may not have a magic ring to protect, but we’re asking the same question. But we’re talking about information.This is the second in a multi-part series on how to apply information security principles and techniques as part of data modeling. This series uses a simple data model designed to manage non-commercial clubs as an example of security approaches. In later articles, we will address modeling for fine-grained access controls, auditing, authentication, and other key aspects of secure database implementation.
“Information is the lifeblood of any organization…” We hear a lot of statements like this, or about an “information age,” or an “information economy.” When we agree with belief that amplifies the importance of information in the world today, we have to consider how to make that all-important information secure. Who can see my bank account? Was the facilities maintenance contract lost? Why can’t I get the latest lab report? The database professional has such concerns magnified by the thousands or millions, and so modeling for data security is critical. Here we look at some issues in securing and controlling access to information stored in a database.
Death and taxes – add “software problems” to that list of the inevitable. There is always a new issue, a new failure, a new key opportunity that an organization must address. And to avoid repeating the problems, or to revise your prior fixes, it is critical to capture the problems accurately and completely. You need a history of what happened and when. In this piece, we create the logical model for a problem or “bug” reporting system.