Posts tagged constraint
The accuracy, internal quality, and reliability of data is frequently referred to using the term ‘data integrity’. Without it, data is less valuable or even useless. This session takes a close look at what data integrity entails and how it can be enforced in multi-tier application architectures using distributed data sources and global transactions. The discussion will make clear which elements are required from any robust implementation of data oriented business rules aka data constraints and it will explain how most existing solutions are not as watertight as is frequently assumed. Steps for achieving reliable constraint enforcement are demonstrated.
The presentation I did last week for the JFall 2013 conference can be checked on SlideShare:
To be useful, data held and used in information systems has to live up to a number of expectations. The data should be an accurate representation of its source. It should be reliable. The data should have internal consistency. The data should adhere to rules based on the logic of the real world. This accuracy, internal quality, and reliability of data is frequently referred as data integrity.
Safeguarding the integrity of data is a challenge, one that increases in complexity when multiple users access and manipulate the data simultaneously , obviously a common situation. And that challenge reaches new heights when the data is managed in multiple independent data stores rather than a single database.
Earlier this month, the Oracle Technology Network published an article that I recently wrote on this subject: http://www.oracle.com/technetwork/articles/soa/jellema-data-integrity-1932181.html. I was triggered into writing it by two recent experiences.
One was at a customer of mine where we are designing a service oriented architecture, based on a number of distinct and independent data domains. These domains are exposed through elementary (entity) services. A second tier of More >
How Oracle Database uses internal locks to make statement level constraint validation robust at the transaction level0
Data Constraints are essential in protecting the integrity of the data in any relational database. The Oracle Database provides four types of declarative constraints that help implement various types of data rules. These are: Primary Key, Unique Key, Foreign Key and Check Constraint. Although these constraints can be configured to be enforced at transaction time (when the transaction is committed) by setting them to be deferred, the default behavior of the constraints is to enforce the integrity rule at statement level. That means that when a transaction performs multiple DML statements, the constraints are validated during execution of the statement. When the statement is done, the integrity is ensured (otherwise the statement would have failed) and additional statements can be executed.
In the multi session environment that is the Oracle Database, you could be wondering – as was I – how the Oracle Database ensures that other sessions executing DML operations can not undermine the integrity of the data touched by the current transaction. And how it can do so without needlessly preventing other sessions to perform data manipulation using various forms of locking.
It turns out that More >
Data Integriteit anno 2011 – Hands-on met Toon Koppelaars en RuleGen 3.0 bij AMIS op dinsdag 27 september0
datum: dinsdag 27 september; 16.30 uur
locatie: AMIS, Edisonbaan 15, Nieuwegein
sprekers: Toon Koppelaars en Lucas Jellema
Het belang van data integriteit behoeft geen toelichting – als het goed is. Vrijwel iedere enterprise applicatie is gebouwd op het fundament van een database. Robuustheid van die database en absolute betrouwbaarheid van de gegevens daarin zijn. essentieel. Het garanderen van die integriteit en robuustheid is lang niet altijd goed geregeld – en is ook geen triviale uitdaging.
De veelheid van toegangskanalen tot de database – batch jobs, web services, web applicaties in Java en .NET, PL/SQL modules en natuurlijk TOAD voor de applicatie beheerder – maakt wel duidelijk dat de integriteitsregels voor de data ofwel de business rules niet in de applicaties of in een service bus (alleen) kunnen worden geÃ¯mplementeerd. Integriteit in moderne applicatie-landschappen kan alleen worden gegarandeerd met implementatie van de business rules in de database zelf.
De Oracle database biedt naast de integrity constraints voor primary, unique en foreign keys weliswaar een veelheid aan mechanismen en constructies maar geen concrete, eenduidige, robuuste en More >
In a previous article, I have introduced RuleGen 3.0 – a 2nd generation business rule implementation framework for the Oracle Database: http://technology.amis.nl/blog/?p=12807. RuleGen provides a solid, structured, scalable framework for database developers to implement data constraints in. This article demonstrates how a moderately complex rule is analyzed and designed and implemented with RuleGen 3.0. If you want to try out RuleGen yourself, you can download the framework under trial conditions from http://www.rulegen.com/free-download .
This article illustrates the essential steps in the business rule design and build process:
- describe the business in human readable format – preferably using names of entities and attributes or even better tables and columns
- analyze the events that potentially violate the business rule and should therefore trigger evaluation of the rule
- define the filter condition (a SQL expression) that identifies the records that should be checked for each triggering event (typically only a very small subset of the records in a table need to be explicitly validated upon an event)
- define the rule validation logic in terms of SQL – write the SQL query More >
RuleGen 3.0 – the latest, leanest and most robust solution for complex data constraints in an Oracle Database0
No matter how complex the enterprise and application architectures become, no matter the number of tiers, services, devices and user interfaces – at the heart of most enterprises will be a relational database.
And no matter how hard we try to implement a fully service based architecture or a multi-purpose business tier (for example using EJBs) – we will have multiple routes to the database and the data in it. Data will be manipulated through web applications, web services, client/server applications, batch database jobs, application managers working directly against the database from the command line or TOAD-like tools. If for no other reason – that by itself is an overridding motivation for enforcing every data constraint at the lowest possible level – the one level that none of these channels can avoid: the database itself. In addition to the fact that only enforcement inside the database can provide real integrity (and what the hack would be semi-real integrity?), for most data rules (especially complex ones) implementation inside the database is the most performant, scalable, maintainable, managable, agile, elegant and easy to implement as well.
Note: I am not advocating that More >