Under certain circumstances, basic operations over tables in a relational database, where integrity reslxictions such as referential and null restrictions have been specified, may produce unpredictable results, not detectable by means of a static analysis of the schema. When the design includes redundancies or when the set of restrictions is contradictory it is easy to detect and prevent future exrors, but there are situations that require a dynamic analysis. In this paper, the properties of networks of referencial integrity reslfictions that contain irregularities are analyzed, and the mtomalies that may appear when data act~mlization in such environment is done are studied in order to define criteria and develop an algorithm to generate rules for proper handling of inconsistencies.

The evaluation of conceptual schemes of actual databases may result in the discovery of inclusion dependencies. An inclusion dependency is defined as the existence of attributes in a table whose values must be a subset of the values of attributes in another table. When the latter set conforms a key for its table, the inclusion dependency is key-based. Key-based inclusion dependencies are fully enforced by most current database systems. On the contrary, if the second set is not the key of the relation, the inclusion dependency is non-key-based. This kind of inclusion dependency is completely disregarded by actual systems, obliging the users to manage them via special-case code or triggers. This implies an excessive effort to maintain integrity and develop applications, among other inconveniences. The chapter goal is to give a heuristics to redesign the conceptual schema. This is based on the identification of hidden business rules and the conversion of non-key inclusion dependencies into key-based ones.

Mapping a database schema from one model into another, with a higher semantic capacity, is a current research subject with application in several development fields, such as schema integration and translation, migration from lega~ systems and revngineering of poor quality or no-longer accurate data models. Inclusion dependencies are one of the most important concepts in relational databases and they are the key to perform some reengineering of database schemas. Referential integrity restrictions (fir), a particular case of an inclusion conslraint, requires that the set of distinct values occurring in some specified column, simple or composite (foreign key), must be a subset of the set of distinct primary key values drawn from the same domain. Pure inclusion dependencies (id), however, may apply between other pairs of attributes also (alternate keys or non-keys). Database schemas containing ids frequently reveal the presence of hidden objects and misrepresented relationships and, as a consequence, incree,se the effort to develop program applications and maintain the integrity. This work presents a heuristics for the conversion of schemas with ids into equivalent schemas with only firs. In case some irreducible ids remain, a semantic interpretation oftbeir necessity and maintenance is given.

Most Web developers underestimate the risk and the level of damage that might be caused when Web applications are vulnerable to SQL (structured query language) injections. Unfortunately, Web applications with such vulnerability constitute a large part of today’s Web application landscape. This article aims at highlighting the risk of SQL injection attacks and provides an efficient solution.

Inclusion dependencies support an essential semantics of the standard relational data model. An inclusion dependency is defined as the existence of attributes (the left term) in a table R whose values must be a subset of the values of the corresponding attributes (the right term) in another table S (Abiteboul, Hull & Vianu, 1995; Codd, 1990; Connolly, Begg & Strachan, 1999; Date, 2000). When the right term conforms a unique column or a primary key (K) for the table S, the inclusion dependency is key-based (also named referential integrity restriction, rir). In this case, the left term is a foreign key (FK) in R and the restriction is stated as R[FK] <