Создать концептуальную схему данных предметной области (предварительную, конечно)

[wldmr-key]

@Ivanovswork - поможешь для начала? (можно помощь не документировать, но, если помощь поможет, то Ксения, уверен,, напишет здесь свое gracias

[Ivanovswork]

Да, конечно

[Ksenia27082004]

Немного объяснений про атрибуты и сущности, которое могут вызвать вопросы:

1. Пользователи: Статус аккаунта – означает на каком этапе пользователь, т.е. подтвержденный аккаунт (при помощи номера телефона) или нет. Статус пользователя – какую роль пользователь имеет, это может быть либо администратор, либо клиент, так как мастера у меня в системе не авторизуются, у них есть только связь только с админом для получения расписания. Является модератором (не смогли придумать более четкого определения для этого атрибута) – это булева переменная, соответственно говорит нам о том, является пользователь модератором или нет

2. Записи: Дата создания – когда создана была запись. Дата приема – когда придет клиент на услугу. Статус – является ли подтвержденной запись или нет (записи подтверждает администратор салона).

3. Отзывы: Оценка – по пятибалльной системе в звездах, т.е. человек оценивает насколько ему понравились салон, мастер и/или услуга.

4. Мастера: Доп. информация – сюда может входить опыт работы мастера, его квалификация, сертификаты по прохождению каких-либо курсов, и, возможно, какая-либо интересная полезная информация о мастере (поэтому решила не делать отдельно атрибуты по опыту работы и т.п.)

5. Услуги: Время – длительность выполнения данной услуги Доп. информация – сюда входит информация в зависимости от услуги, тут могут быть как составы, которые использую мастера для своих процедур, так и виды и бренды красок, какая-либо уходовая косметика для волос.

6. Мастера-услуги – сущность для связи мастера с услугой. Какой мастер какие делает услуги и какую услугу какие мастера могут делать.

7. Строки записи – сущность, соединяющая записи и мастера-услуги. Сюда попадает именно тот мастер (один), которого мы выбрали, когда начали записываться на какие-либо услуги в салон.

[wldmr-key]

Ты зря выбрала такой траурный фон. Схема стала намного лучше ))

Если серьезно, то лучше сразу готовить схему в таком виде, чтобы она без переделок пошла в РПЗ и в графические материалы

Записи-статус - а еще клиент может не явиться и услуга может быть оказана, думаю

понравились салон, мастер и/или услуга - все в одной куче?

А где появляется цена (или диапазон цен)? У услуги или у мастера/услуги?

Строки записи - бестолковая сущность для твоей концептуальной схемы - она ничего не поясняет. В данном случае логичнее свзь "многие ко многим"

Что-то не увидел упомянутого тобой расписания. Смотрел плохо?

[Ivanovswork]

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

Насчет расписания, я представлял себе это так: пользователь выбирает дату в интерфейсе, идет запрос записей у этого мастера на эту дату. Если есть записи есть, то соответствующие ячейки со временем становятся неактивными, если нет записей, то ячейки можно выбрать. Пользователь допустим набрал на 2 часа услуг, тогда автоматически будут выбираться 2 ячейки. Если нет двух свободных ячеек рядом, то нужно выбирать другую дату.

Что-то типа этого

[wldmr-key]

у тебя как-то получилось сделать так, что схема видна только тебе (у меня и Никиты) твое изменение не отображается. но я его нашел https://github-production-user-asset-6210df.s3.amazonaws.com/145330240/370456588-b9d08f6f-47c7-41c1-85da-4d818d2ae487.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240927%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240927T202507Z&X-Amz-Expires=300&X-Amz-Signature=ef6ed790dae54aa48b09c1dc7ea9eb34e7e7ebc94aa99b586bcd1a31cfe1cd6a&X-Amz-SignedHeaders=host

[wldmr-key]

связь "записи-мастера" не выглядит обоснованной по твоему описанию

обрати внимание на амбициозность своей задачи: если клиент выбрал стрижку у одного мастера, а окрашивание у другого (про третьего даже боюсь упоминать), то при записи ты должны синхронизировать свободные часы у обоих. Осилишь?

Сегодян на консультации обсуждали с Никитой проблемы расписания - думаю, он с тобой поделится своими мыслями

[Ksenia27082004]

Все нюансы по связям и атрибутам описала в требованиях к системе

[wldmr-key]

тебе не кажется, что доступные и занятые слоты - оо-о-о-очень похожи? ))

[Ivanovswork]

Вот и мне так кажется. Во время того, как мы это делали, я потерял нить необходимости сущности доступные слоты, в случае с произвольным расписанием, ведь можно сделать тайм-слоты с типом. Решил довериться нашему обсуждению в зуме.

Но с другой стороны, тайм-слоты это развязка с доп. атрибутами связи многие ко многим между мастера-услуги и записями. По мне как-то странно добавлять туда свободные слоты, так как у них не будет связей записями и мастерами-услугами. Пустые внешние ключи - как-то странно. Поэтому опять ко мне приходит вывод, что в этом есть необходимость.

Возможно я не вижу другого, более изящного решения.

[wldmr-key]

как по мне, так свободные слоты выглядят более изящно совмещенными с занятыми (и для программирования/запросов одна таблица завсегда удобнее)

нулевой внешний ключ - это нормальное явление, которое интерпретируется, как отсутствие связи. Таким образом, если в слотах есть экземпляр, который ссылается только на мастера - то это его свободное время. Когда оно бронируется, появляются ссылки на услугу (ключ- мастер-услуга, конечно) и запись.

По-моему, логично и экономично ))

[Ksenia27082004]

[wldmr-key]

сразу просмотрел - сейчас вижу - отзывы теперь относятся только к записям? А, стоит ли делать для них сущность? Лишняя таблица, лишний класс в программе...

[Ivanovswork]

ну мне кажется надо было перенести атрибуты отзыва в запись, а не слово отзыв

[Ksenia27082004]