I would have to agree, the use of NULL itself does not violate RFI.

Even a simple definition via Google clarifies what RFI really is. All RFI is really doing is making sure the relationships exist between tables to maintain data consistency. "Each non-null value of a foreign key must match the value of some primary key." - Information Modeling and Relational Databases; Halipin

So being NULL itself is not the issue but I see his point that come columns that are NULL may be designed poorly and should be NOT NULL. Wouldn't this only be an RFI issue if the application layer was maintaining RFI and not the DB? If one was using the App layer to do this then I could see how data could be inconsistent and the DB would be subject to mistakes made by the application code. This usually results in duplicate records or orphaned records.

An excerpt from an article I am writing for developers in my company:

"There is no one absolute best answer when asking how to implement RFI whereas scenarios will dictate the requirements but there are two primary schools of thought for most databases. The first, and by the way the best practice, is to maintain RI within the database. After all, SQL Server is a relational database management system (RDBMS). Why not let it do what it was designed to do? The second school of thought is to allow software code, within an application, to do this. This quite frankly may have its benefits in limited implementations, such as cross system integrity, but it is fraught with peril and relies on very attentive programmers and acute domain knowledge of the software and database by programmers. It is important to note that the software implementation of referential integrity does not follow Edgard F. Codd's 12 Rules for a relational database listed above. A third option is to mix these two solutions."