Yes, it's atomic; your domain is the ISBN. If you were storing the domains for ISBNPrefix, ISBNRegistrationGroup, ISBNRegistrant, ISBNPublication and ISBNCheckDigit, then you'd split it up.
Consider the North American phone number +1-234-567-8901 ext 234567
. Many systems choose to store such a number under two domains, such as PhoneNumber
and PhoneNumberExtension
, taking perhaps 2345678901
under the PhoneNumber
domain and 234567
under the PhoneNumberExtension
domain, ignoring the Phone Number Country Code altogether ( largely because it is always 1 ). Since the domains are defined as such, it is not incorrect to store them in such a manner. An example of violating 1NF in this case would be to store multiple extension numbers in the same row for a singular entity existing in the PhoneNumber
domain.
| PhoneNumber | PhoneNumberExtension |
2345678901 234567, 890123
Instead, to preserve 1NF, the PhoneNumberExtension
attributes are stored separately.
| PhoneNumber | PhoneNumberExtension |
2345678901 234567
2345678901 890123
A system with more granular domains may choose to store phone numbers by PhoneNumberCountryCode
, PhoneNumberAreaCode
, PhoneNumberPrefix
, PhoneNumberLineNumber
and PhoneNumberExtension
| CountryCode | AreaCode | Prefix | LineNumber | Extension |
1 234 567 8901 234567
Since the domains are defined in such a way, it is again not incorrect to store the data as such. The same logic applies to various "compound attributes," like your ISBN; geographical coordinate data and municipal mailing addresses are some common examples, but such "Domain grouping" happens even in basic data types - consider DATETIME
, a raw datatype for an example - one part date, one part time.
The way you choose to define your domains will largely be a decision on how you intend to use them. In the telephone example, there tends to be little value in breaking apart AreaCode
since other more appropriate demographics are often available, such as City
, though splitting the domain apart is not a "wrong" choice. If there is little value for your purposes to split apart the ISBN, you are not violating 1NF by defining the domain on a less granular level - you just can't store two of them in the same row for the same entity.