Return to Answer

Answer after the question was edited:

There are several issues with the depicted data. The most serious is a violation of third normal form in the second table, since, weekday-name and weekend-flag will always be the same for a given weekday number - but weekday number is not a unique for the table. Therefore weekday-name and weekend flag should be extracted to a separate lookup table.

There is arguably a redundancy by even storing weekday number for each date, since weekday can be algorithmically determined from the date. But this is not strictly a violation of normalization, and storing the weekday may be justified for practical reasons.

Then there is a 1:1 relationships between the two table depicted, which is not a violation of normalization either, but problematic since it makes inserts more complex and have a have a cost in joins.

It seems like the PK and dow column in the first table and the PK table in the second table all contain the same information. This could indicate redundant data, although it depends on the meaning of the data and whether there are foreign keys defined on them.

I don't think there is a common term covering these issues, except the rater general "redundant data".

Violation of normalization is typically due to bad database design, but in some cases it may be deliberate for performance reasons. Same with 1:1 relationships (which is sometimes called vertical partitioning or row spitting) which may speed up certain queries.

The combination of denormalization and row spitting might indicate a database optimized for analytics but it could also just be a really badly designed OLTP database.

Original answer:

What you see is called vertical partitioning or row splitting or sixth normal form.

Having repeated values in a column is not in itself problematic. E.g. if you have a boolean column you will have lots of repeated values, but this is perfectly fine.

Having 1:1 tables (as this example seem to be) does not violate normalization. But from a practical perspective, it is more inconvenient for queries and updates than just having a single table. But there may be practical considerations which offset this inconvenience. Some I can think of:

• Performance: In some cases performance can be increased by vertical partitioning of tables.

• Organization or permissions: The columns may "belong" to different applications or departments and have different access rights.

It might also be that the data is actually one-to-many, but just one-to-one in most cases. E.g. most people have one nationality, but a small fraction has multiple.

Bottom line: You have to bite the bullet and ask the person who designed this for the reason. You should be open to the possibility that it is designed like that for a good reason.

It sounds like you are searching for a justification to dismiss this design without needing to understand the rationale first. And the other party says you "don't understand" the solution. Honestly, it seems more of a peoples or communication issue rather than a database design issue.

Answer after the question was edited:

There are several issues with the depicted data. The most serious is a violation of third normal form in the second table, since weekday-name and weekend-flag will always be the same for a given weekday number - but weekday number is not a unique for the table. Therefore weekday-name and weekend flag should be extracted to a separate lookup table.

There is arguably a redundancy in even storing weekday number for each date, since weekday can be algorithmically determined from the date. But this is not strictly a violation of normalization, and storing the weekday may be justified for practical reasons.

Then there is a 1:1 relationship between the two tables depicted. This is not strictly a violation of normalization either, but problematic since it makes inserts more complex and has a cost in joins. 1:1 relationships are sometimes used deliberately in a pattern called vertical partitioning or row splitting, but then the partitions usually share the same primary key. Unless other tables in the database have a foreign key to the second table, the partitioning does not seem useful.

I don't think there is a common term covering these issues, except the rater general "redundant data". But the violation of 3rd normal form in itself should be enough to request a redesign of the schema.

Violation of normalization is typically due to bad database design, but in some cases it may be deliberate for performance reasons. Especially in databases designed for analytics (rather than OLTP) like in data-warehouses, denormalization and row-splitting is often used to optimize certain analysis.

It could also just be that the second table is a mistaken attempt to create a lookup table.

Original answer:

What you see is called vertical partitioning or row splitting or sixth normal form.

Having repeated values in a column is not in itself problematic. E.g. if you have a boolean column you will have lots of repeated values, but this is perfectly fine.

Having 1:1 tables (as this example seem to be) does not violate normalization. But from a practical perspective, it is more inconvenient for queries and updates than just having a single table. But there may be practical considerations which offset this inconvenience. Some I can think of:

• Performance: In some cases performance can be increased by vertical partitioning of tables.

• Organization or permissions: The columns may "belong" to different applications or departments and have different access rights.

It might also be that the data is actually one-to-many, but just one-to-one in most cases. E.g. most people have one nationality, but a small fraction has multiple.

Bottom line: You have to bite the bullet and ask the person who designed this for the reason. You should be open to the possibility that it is designed like that for a good reason.

It sounds like you are searching for a justification to dismiss this design without needing to understand the rationale first. And the other party says you "don't understand" the solution. Honestly, it seems more of a peoples or communication issue rather than a database design issue.

Answer after the question was edited:

There are several issues with the depicted data. The most serious is a violation of third normal form in the second table, since, weekday-name and weekend-flag will always be the same for a given weekday number - but weekday number is not a unique for the table. Therefore weekday-name and weekend flag should be extracted to a separate lookup table.

There is arguably a redundancy by even storing weekday number for each date, since weekday can be algorithmically determined from the date. But this is not strictly a violation of normalization, and storing the weekday may be justified for practical reasons.

Then there is a 1:1 relationships between the two table depicted, which is not a violation of normalization either, but problematic since it makes inserts more complex and have a have a cost in joins.

I don't think there is a common term covering all three issues.

Violation of normalization is typically due to bad database design, but in some cases it may be deliberate for performance reasons. Same with 1:1 relationships (which is sometimes called vertical partitioning or row spitting) which may speed up certain queries.

The combination of denormalization and row spitting might indicate a database optimized for analytics but is could also just be a relly badly designed OLTP database.

Original answer:

What you see is called vertical partitioning or row splitting or sixth normal form.

Having repeated values in a column is not in itself problematic. E.g. if you have a boolean column you will have lots of repeated values, but this is perfectly fine.

Having 1:1 tables (as this example seem to be) does not violate normalization. But from a practical perspective, it is more inconvenient for queries and updates than just having a single table. But there may be practical considerations which offset this inconvenience. Some I can think of:

• Performance: In some cases performance can be increased by vertical partitioning of tables.

• Organization or permissions: The columns may "belong" to different applications or departments and have different access rights.

It might also be that the data is actually one-to-many, but just one-to-one in most cases. E.g. most people have one nationality, but a small fraction has multiple.

Bottom line: You have to bite the bullet and ask the person who designed this for the reason. You should be open to the possibility that it is designed like that for a good reason.

It sounds like you are searching for a justification to dismiss this design without needing to understand the rationale first. And the other party says you "don't understand" the solution. Honestly, it seems more of a peoples or communication issue rather than a database design issue.

Answer after the question was edited:

There are several issues with the depicted data. The most serious is a violation of third normal form in the second table, since, weekday-name and weekend-flag will always be the same for a given weekday number - but weekday number is not a unique for the table. Therefore weekday-name and weekend flag should be extracted to a separate lookup table.

There is arguably a redundancy by even storing weekday number for each date, since weekday can be algorithmically determined from the date. But this is not strictly a violation of normalization, and storing the weekday may be justified for practical reasons.

Then there is a 1:1 relationships between the two table depicted, which is not a violation of normalization either, but problematic since it makes inserts more complex and have a have a cost in joins.

It seems like the PK and dow column in the first table and the PK table in the second table all contain the same information. This could indicate redundant data, although it depends on the meaning of the data and whether there are foreign keys defined on them.

I don't think there is a common term covering these issues, except the rater general "redundant data".

Violation of normalization is typically due to bad database design, but in some cases it may be deliberate for performance reasons. Same with 1:1 relationships (which is sometimes called vertical partitioning or row spitting) which may speed up certain queries.

The combination of denormalization and row spitting might indicate a database optimized for analytics but it could also just be a really badly designed OLTP database.

Original answer:

What you see is called vertical partitioning or row splitting or sixth normal form.

Having repeated values in a column is not in itself problematic. E.g. if you have a boolean column you will have lots of repeated values, but this is perfectly fine.

Having 1:1 tables (as this example seem to be) does not violate normalization. But from a practical perspective, it is more inconvenient for queries and updates than just having a single table. But there may be practical considerations which offset this inconvenience. Some I can think of:

• Performance: In some cases performance can be increased by vertical partitioning of tables.

• Organization or permissions: The columns may "belong" to different applications or departments and have different access rights.

It might also be that the data is actually one-to-many, but just one-to-one in most cases. E.g. most people have one nationality, but a small fraction has multiple.

Bottom line: You have to bite the bullet and ask the person who designed this for the reason. You should be open to the possibility that it is designed like that for a good reason.

It sounds like you are searching for a justification to dismiss this design without needing to understand the rationale first. And the other party says you "don't understand" the solution. Honestly, it seems more of a peoples or communication issue rather than a database design issue.

What you see is called vertical partitioning or row splitting or sixth normal form.

Having repeated values in a column is not in itself problematic. E.g. if you have a boolean column you will have lots of repeated values, but this is perfectly fine.

Having 1:1 tables (as this example seem to be) does not violate normalization. But from a practical perspective, it is more inconvenient for queries and updates than just having a single table. But there may be practical considerations which offset this inconvenience. Some I can think of:

• Performance: In some cases performance can be increased by vertical partitioning of tables.

• Organization or permissions: The columns may "belong" to different applications or departments and have different access rights.

It might also be that the data is actually one-to-many, but just one-to-one in most cases. E.g. most people have one nationality, but a small fraction has multiple.

Bottom line: You have to bite the bullet and ask the person who designed this for the reason. You should be open to the possibility that it is designed like that for a good reason.

It sounds like you are searching for a justification to dismiss this design without needing to understand the rationale first. And the other party says you "don't understand" the solution. Honestly, it seems more of a peoples or communication issue rather than a database design issue.

Answer after the question was edited:

There are several issues with the depicted data. The most serious is a violation of third normal form in the second table, since, weekday-name and weekend-flag will always be the same for a given weekday number - but weekday number is not a unique for the table. Therefore weekday-name and weekend flag should be extracted to a separate lookup table.

There is arguably a redundancy by even storing weekday number for each date, since weekday can be algorithmically determined from the date. But this is not strictly a violation of normalization, and storing the weekday may be justified for practical reasons.

Then there is a 1:1 relationships between the two table depicted, which is not a violation of normalization either, but problematic since it makes inserts more complex and have a have a cost in joins.

I don't think there is a common term covering all three issues.

Violation of normalization is typically due to bad database design, but in some cases it may be deliberate for performance reasons. Same with 1:1 relationships (which is sometimes called vertical partitioning or row spitting) which may speed up certain queries.

The combination of denormalization and row spitting might indicate a database optimized for analytics but is could also just be a relly badly designed OLTP database.

Original answer:

What you see is called vertical partitioning or row splitting or sixth normal form.

Having repeated values in a column is not in itself problematic. E.g. if you have a boolean column you will have lots of repeated values, but this is perfectly fine.

Having 1:1 tables (as this example seem to be) does not violate normalization. But from a practical perspective, it is more inconvenient for queries and updates than just having a single table. But there may be practical considerations which offset this inconvenience. Some I can think of:

• Performance: In some cases performance can be increased by vertical partitioning of tables.

• Organization or permissions: The columns may "belong" to different applications or departments and have different access rights.

It might also be that the data is actually one-to-many, but just one-to-one in most cases. E.g. most people have one nationality, but a small fraction has multiple.

Bottom line: You have to bite the bullet and ask the person who designed this for the reason. You should be open to the possibility that it is designed like that for a good reason.

It sounds like you are searching for a justification to dismiss this design without needing to understand the rationale first. And the other party says you "don't understand" the solution. Honestly, it seems more of a peoples or communication issue rather than a database design issue.