Some application developers who have created API code have developed ways of keeping that code in the database too, as attachments, and having it detached automatically by the Notes application, so leveraging the replication model to distribute non-Notes application components.

2. Notes has no schema, and does not implement Referential Integrity
Notes doesn't have a schema. It has no concept of tables or keys, and so cannot implement referential integrity. As far as Notes is concerned, all data notes are data notes; differentiation between them is down to their contents only, and not to any structural attributes.

For example, the field FORM is used by the Notes UI to tell what Notes form -- screen mask -- is to be used to display note data on the screen. Another example: views, which act as database indexes, have a selection formula; the developer uses this to select the data notes that are to be included in that view.

Commonly the Form field value is used, which is about as close as Notes gets to an RDBMS table. A view can be sorted, and the first sorted column is about as close as Notes gets to table keys.

Because of this, Notes does not have Referential Integrity, and could not. If it is required in an application, standard Notes design and programming techniques are used to create an RI model for the application. The only structural relationship that Notes implements is the Response Hierarchy, which provides a parent-child relationship of documents.

For example, this is used in discussion type applications so that views, which can be made sensitive to this relationship, will generate and display threads of responses. It's implemented by a pointer field in the response which points to its immediate parent. It does not have any rules attached to it, so that it is entirely possible to delete any document in the thread, and so logically break the thread. It's up to the application developer either to prevent this happening, or to write code that repairs the thread.

A complete Notes application may also be several Notes databases. Notes of itself does not have any mechanism for management of relationships between these databases. For sure, there are programming fundamentals and tools for building multi-database applications, so that one database can look up, use and update data in another one, but Notes of itself does not know of, understand or maintain these for itself. If required, they have to be programmed.

3. Notes may keep Data as part of Design.
The most obvious implementation of this is the Notes keyword field. This is a partial implementation of constraint tables, in that it is used to provide a fixed list of values that can be entered into a field, but does not stop non-listed values being inserted into the field programmatically, because the keyword list is part of the UI object used to display the data, and isn't an attribute of the storage of the data itself.

Keyword fields have a variety of implementations, in that choices can be a fixed or extendable list, can be displayed as a list choice, radio or checkboxes. The keyword list data can be canned in the design or looked up elsewhere in the same or another Notes application, or, with appropriate drivers, in an external database. Note that this last is not a good implementation choice, because it's hard to distribute.