Storing data that can be accessed outside the database itself, goes against the 1st Normal Form?

Asked

Viewed 66 times

3

For example, I have an invoice, which I can consult in another database (but not of my property), an example would be Pagseguro. I store only the invoice identification number to be able to consult.

Here comes the doubt, storing these data that can be accessed would conflict with the standardisation of databases, more specifically, with 1FN - 1st Normal Form?

database modeling software-engineering normalization

  • Instead of keeping alone numero de identificação you want to know if save all other information will violate the 1FN?

  • That’s right, if you store this data that can be accessed, it would violate...

  • 3

    Relevant topic: http://answall.com/q/151323/132

  • 1

    I imagine you want to save everything in case of an unavailability, I don’t see that violating 1FN. A violation can occur for two reasons columns with duplicate information ex: a table with 2 or more fields for phones or emails and have multivariate fields.

2 answers

4


Storing in a separate table in your database would not violate the first normal form. This normalization does not impose anything that information should be somewhere outside, it refers to the relational model of your database. Storing in the same table will be a violation.

The question is whether the result will be as expected. Can the data in the external resource change? What happens if this occurs? Do you want the data in your database to be updated as well, or is it ideal that it remains as it was at the time of use? If it is the last option, how do you resolve if the external information is used again is different? I doubt it’s the case of an invoice, but I don’t know how they operate.

Regardless of the answer, do what you need to do. Don’t be worried about whether you’re in the normal form or not. It’s good that you are, but if you have reason not to follow the normal way, don’t, it’s not mandatory. If you start doing it because someone said you should always do it this way, you’ll be doing it wrong. Do what’s right for your project. Denormalizing is interesting too.

I don’t know the case in detail, but I would probably bring the data to my base so it doesn’t depend on external resources. Depending on the case there may be a need for a verification mechanism if the data is up to date.

  • I also think in this way, of wanting to store in the given basis so as not to have to depend on external resources. And about the data change of the external resource, the only information that can change, is the payment status, which in case already stored at each change (receiving a notification by Pagseguro POST)

3

Not. The first normal way dictates that you can’t have multivariate columns, and that’s not what you’re having. Relevant topic for further clarification: What is database normalization?

Once you store the invoice number to be consulted, this is the analog to a foreign key. This does not constitute (at least not by itself) any violation in any normal way, let alone the normal first form. Despite this, it is still possible that you may be violating some normal form depending on where or how you store it.

In addition, the concept of standardisation applies to the relational database. Your case is not a relational database, at least not purely, but a database distributed by web services. Therefore, you cannot invent an SQL query that does joins including data from your invoice tables, because the Pagseguro web service doesn’t work that way, and another approach would be needed. Moreover, since the data are kept in separate places and controlled by different entities, there are no ready guarantees referential integrity.

Browser other questions tagged database modeling software-engineering normalization

You are not signed in. Login or sign up in order to post.