БД для Дома детского творчества

[.Phoenix]

Сменил схему, но столкнулся с любопытным моментом. Если воспитанник ходит на несколько кружков, то придётся делать еще одну запись верно? Т.е. почти всё будет одинаково, кроме названия секции. Т.е. тем самым схема данных не дает шанс совпадениям, даже если применить код воспитанника или привязать таблицу через родителя...Интересно, кто как поступил на этом этапе разработки бд.
2badboychik. найс схема

[psycho-coder]

Ну народ, вы жгёте ) вот правильная схема, щас запросы нарисую

Жжети Как раз Вы. Зачем разделять Школу, Класс и ПОЛ!? это связи один-к-одному, т.е. фактически одна таблица разбитая на две
Я это пишу не потому что мне на понравилась Ваша структура, она вполне нормальная, за исключением несколько моментов, а потому что у меня уже есть некоторый опыт по проектированию БД. Опыт пусть небольшой но все же есть. На некоторые грабли уже наступал.

Сменил схему, но столкнулся с любопытным моментом. Если воспитанник ходит на несколько кружков, то придётся делать еще одну запись верно? Т.е. почти всё будет одинаково, кроме названия секции. Т.е. тем самым схема данных не дает шанс совпадениям, даже если применить код воспитанника или привязать таблицу через родителя...Интересно, кто как поступил на этом этапе разработки бд.

Для этого используются связь многое-ко-многим. Настоятельно рекомендую почитать эту книгу.

но будут ли работать запросы из – за которых началась вся заварушка

Да, запросы работать будут! Они не сложные, бывали и по сложнее

[badboychik]

Зачем разделять Школу, Класс и ПОЛ!? это связи один-к-одному, т.е. фактически одна таблица разбитая на две

Как это одна? Список школ в своей таблице, список классов в своей. С какой стати это одна таблица? А связываются эти данные с таблицей "Ученики". Что то вы путаете

Для этого используются связь многое-ко-многим

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

Трудность возникла при подсчете количества секций посещаемых одним ребенком. А также как составить запрос: сколько детей посещают определенное количество секций.

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

Кстати про родителей и руководителей я не делал, только исправил ту схему что была. Там вообще был ужас, извините конечно. Могу добавить если надо родителей и все такое. Только сформулируйте все требования в одном месте и поконкретнее

[.Phoenix]

Немного переделал, как такая версия?

[psycho-coder]

Как это одна? Список школ в своей таблице, список классов в своей. С какой стати это одна таблица? А связываются эти данные с таблицей "Ученики". Что то вы путаете

Хм.. Может быть. Но Пол то нафига выносить в отдельную таблицу? Разве булевого поля недостаточно?

В базе ни в коем случае не должно быть связей "многие-ко-многим"

Это как раз Вам следует знать что: реляционная модель не поддерживает связь многие-ко-многим! И то что нужно разделять такие таблицы я знаю. Эта связь абстрактная модель, простое выражение, дающее людям понять структуру БД. Если бы Вы присмотрелись повнимательней в мой скрипт на SQL и мою схему данных, то могли бы увидеть что там это реализовано.

Ладно хватит холиварить. Я тогда отключаюсь от темы. Тут и без меня есть двое разработчиков.

Желаю хорошо все закончить! Удачи вам badboychik, .Pheonix

[badboychik]

.Phoenix, в схеме неправильная связь "Воспитанники - Родители". Во первых она должна быть направлена наоборот, во вторых где поле КОД в таблице родителей?
Еще - связь один-к-одному между воспитанниками и некой "основной таблицей" не нужна, там должна быть 1-к-многим. Один воспитанник может ходить в несколько секций

А если делать вместо пола булевы значения, потом придется везде преобразовывать 0 в "м", 1 в "ж" например

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

[saya771]

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

[.Phoenix]

saya771 если я правильно понял, то в одну секцию он мог поступить, например, в 2008, а в другую 2009, но закончить обе в 2010. Я правильно понял?

[saya771]

.Phoenix правильно, а может одну секцию закончить, а во вторую ходить 9 лет. И за это время ещё побывать в нескольких секциях, а выпускником быть только одной секции, то есть пройти курс обучения от начало до конца.

[.Phoenix]

saya771 Понял
Скинул скрин.