Какого красивого дяденьку к нам занесло.

БредятинаУ Вас огромное количество ошибок. Поясню на примере. Фамилия, конечно же, является самостоятельной сущностью, а вовсе не свойством сущности Клиент , как у Вас. И т.д. То есть, до третьей нормальной формы Вам еще как до луны))

КЛАСС!

Если Вам непонятно, что у фамилии есть, например, происхождение, то, конечно, Вам еще рано заниматься нормализацией )) Нужно закончить среднюю школу, для начала))

ЕЩЁ ЛУЧШЕ!!

Разумеется, если опираться на "функциональные зависимости" и "ключи". К счастью, все намного проще. Достаточно ответить на вопрос: не является ли это свойство свойством какой-то другой сущности или самостоятельной сущностью?)

ПРАВИЛЬНО, КЛЮЧИ НАХ, КАК БУРЖУАЗНЫЙ ПРЕДРАССУДОК!!!

Исключено. Практик никогда не задаст такой вопрос. Ваша ирония уместна, конечно. Я опять забыл, что здесь собрались практики, не имеющие представления о теории БД)) И что самое печальное - о практике проектирования БД)) Они вместо элементарных вопросов, которые нужно задавать себе, а вовсе не пользователям (пользователям задают совсем другие вопросы), задают бесконечно один, еще более элементарный, вопрос: я правильно нормализовал данные? Мне удалось получить 3НФ?:)
Понятно, что это неразрешимая, видимо, проблема высшего образования. Но ведь и самообразование никто не отменял..

ЧТО-Ж, КРИТИКА ПРИНИМАЕТСЯ, ПРИДЁТСЯ ПЕРЕКВАЛИФИЦИРОВАТЬСЯ В УПРАВДОМЫ.

У местных "теоретиков" весеннее обострение?))) "Фамилия сама по себе не может..." Приговор, основанный на низком уровне преподавателей наших "теоретиков". С этим, как я уже сказал в предыдущем сообщении, ничего не поделаешь...

НАШИХ ПРЕПОДАВАТЕЛЕЙ ТОЖЕ В УПРАВДОМЫ

Там еще пикселы, наверное... Но, то что подумали - уже хорошо:)

СПАСИБО, ЧТО ПОХВАЛИЛ, ДОБРЫЙ ЧЕЛОВЕК

А, так вам, дорогие, БД уже не интересны, вы о гостинице?))) И о фамилиях и именах на форменной одежде сотрудников. Тоже, наверное, интересная проблема)))

Надо что? Надеюсь, Вы понимаете, что мое предположение о большом количестве ошибок в проекте - провокация)) Автор должен понять, если он хочет заниматься базами данных, что проблемы вовсе не в том, о чем "ему сказали". Тем более, что ему сказали некорректно: для связей многие ко многим не нужно "создавать еще одну таблицу" (ведь в постановке задачи не прозвучало требования использовать реляционную СУБД)...

ПРАВИЛЬНО, НУЖНО КАКУЮ-НИБУДЬ НЕРЕЛЯЦИОННУЮ, ПУСТЬ ПРЕПОД ОБЛАЖАЕТСЯ, КОГДА НЕ СМОЖЕТ ПОНЯТЬ, ЧТО СТУДЕНТ ЕМУ ПРИНЁС

Обратите внимание, на следующие очевидные вопросы, которые Вы должны себе задать:
1) Стоимость номера не меняется с течением времени (например, в связи с инфляцией)?
2) Одинаковая стоимость у номеров одного типа или у каждого номера своя стоимость?
3) В номере могут проживать бесчисленное множество человек одновременно ?
Лучше было бы уточнить это у преподавателя. Раз он не смог сформулировать задачу так, чтобы вопросов не возникало:)

ПУСТЬ ТАМ ЖИВУТ ВСЕ СОТРУДНИКИ ЧЕРКИЗОВСКОГО РЫНКА,

Если предположить, что:
1) Стоимость определяется для Типа номера.
2) Стоимость не изменяется в течение очередного сезона.
3) Единицей измерения услуги - сутки (с одним и тем же временем начала).
4) В номере может проживать бесчисленное множество человек.
То (не рекомендую использовать реляционную СУБД , но она Вам навязана, поэтому ключи вместо связей между сущностями):

Постоялец {Ид. постояльца, Фамилия, Имя, Отчество, Дата рождения}
Тип номера {Ид. типа, Наименование}
Номер {Ид. номера, Номер, Ид. типа(FK)}
Проживание {Ид. проживания, Ид. постояльца(FK), Ид. номера(FK), Дата въезда, Дата выезда}
Вид из номера {Ид. вида, Ид. номера(FK), Фото}
Сезон {Ид. сезона, Дата начала, Дата окончания} ОЦ: сезоны не пересекаются и между ними нет промежутков
Прейскурант {Ид. прейскуранта, Ид. типа(FK), Ид. сезона(FK), Стоимость суток}

ПОНЯЛИ?! НЕ РЕКОМЕНДУЮТ!!!

1) Точно не кашист))
2) Извините, что не читал Ваши сообщения, привык уже, что в них не может быть ничего интересного)
3) А пару (всего???) ошибок в своем сообщении Вы, надеюсь, исправите самостоятельно))

НЕ, НА УПРАВДОМА НЕ ПОТЯНЕМ, СТАРШИЙ ПО ПОДЪЕЗДУ, ВОТ НАШ ПОТОЛОК