Все намного сложнее.

Насколько я понял, есть тип гостинничных номеров, цена на которые зависит от даты заезда.
Тут пройдет простая таблица

Код_номера
Цена
Начало_действия_цены

Это теоритески правильная таблица

Но выборки по ней будут сложные. Нужно будет определять в какой диапазон попадает цена.
Сначала надо найти начало диапазона цен, где дата_заезда больше иили равно ее, а потом найти его окончание, где дата заезда меньше ее.

Поэтому, лично я предпочел бы некоторую денормализацию

Код_номера
Цена
Начало_действия_цены
Конец_действия_цены

Денормализация заключается в том, что Конец_действия_цены может быть получен на основании других данных, но я объявляю ее явно.

Цена на номер может быть привязана к году. Ведь со временем цены меняются?


Тогда таблица будет иметь вид

Год
Код_номера
Цена
Начало_действия_цены
Конец_действия_цены

В полях Начало_действия_цены и Конец_действия_цены нужно указывать не DateTime, а месяц и день. В двух полях или в одном - не приципиально

Это, однако, не аккуратно.Ведь цены могут поменятся в произволный период времени? Не обязательно 1 января.


Уже две таблицы получаются

Таблица Прайсы

Прайс_название
Прайс_код
Начало_действия_ прайса

Таблица цены_номеров

Прайс_код
Код_номера
Цена
Начало_действия_цены
Конец_действия_цены


И, опять я бы денормализовал.

Таблица Прайсы

Прайс_название
Прайс_код
Начало_действия_ прайса
Конец_действия_ прайса (у актуального = 9999 год)


Таблица цены_номеров

Прайс_код
Код_номера
Цена
Начало_действия_цены (день, месяц)
Конец_действия_цены (день, месяц)


Казалось бы - избыточная информация, достаточно только актуального прайса. Но представьте момент, что надо поднять данные, сколько стоил номер 1879 году?

rulez22Вроде бы сделал по твоему варианту, можешь проверить типы полей и самое главное связи таблиц? Верно ли я сделал? См. аттач
Нет. Не совсем. Я же подчеркивал, что окончание и начало периода действия цены нужно хранить как день и месяц.

Годовой интервал - это день и месяц начала, день и месяц конца, а не дата. Конечно, можно хранить датой и выбирать из нее только день и месяц, но это, на мой взгляд, неаккуратно - в базе появляется избыточная и ненужная информация, которая может сбить с толку. Ведь в этом случае дату начала можно хранить как 01.01.9999, а дату конца - 01.02.1812.
Нелогично.

Как хранить день-месяц, в одном поле в строчном формате "mmdd" или в двух целочисленых - дело вкуса. Как в проге будет удобнее проверять вхождение.


То есть, алгоритм поиска цены должен быть такой.
1. Находим, какой прайс действовал в искомую дату
2. Находим в этом прайсе, в какой годовой интервал попадает искомая дата.
3. Смотрим, какая этому интервалу соответствует цена.

==========
Правильно ли сделаны в прилагаемой базе связи - не смотрел. Я на Access не работаю и даже не знаю, где это глянуть.