The mistake is in your understanding of transitive dependency. From wikipedia: Transitive dependency
In mathematics, a transitive dependency is a functional dependency which holds by virtue of transitivity. A transitive dependency can occur only in a relation that has three or more attributes. Let A, B, and C designate three distinct attributes (or distinct collections of attributes) in the relation. Suppose all three of the following conditions hold:
1. A → B
2. It is not the case that B → A
3. B → C
Then the functional dependency A → C (which follows from 1 and 3 by the axiom of transitivity) is a transitive dependency.
In your case though, (2) does not hold:
1. U → T -- correct
2. It is not the case that T → U -- wrong
3. T → V -- correct
Therefore {V} is NOT transitively dependent on {U}.
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.
Best Answer
1NF requires that every attribute position in every tuple in every relation contains a single value of the appropriate type. The types can be arbitrarily complex. In fact, the types can be relations. (CJ Date's book Database in depth: relational theory for practitioners treats this issue in a way that's pretty easy to understand.)
"Atomic" has never really meant "indivisible", which is why that term is finally falling out of favor. Loosely speaking, "atomic" means if a value has component parts, the dbms either ignores the existence of those parts, or it provides functions to manipulate them. For example, a timestamp value has these parts.
That kind of value is obviously divisible, and all database management systems provide functions to manipulate those parts. They also provide a way to select a timestamp as a single value. (Which, of course, it is.)