О разработке структуры базы данных (для начинающих) (обсуждение статьи)

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

3

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

0

После столь бурного обсуждения осмелюсь все-таки еще раз задать вопрос, на который ответа не прозвучало.
Я прочитала статью Ameli с примером разработки БД. Все очень подробно, доходчиво, логично описано. Но что касается таблиц из двух полей КОД и НАЗВАНИЕ, то я делаю не так и цель моего вопроса была разобраться, чем это мне может грозить в дальнейшем.
С нормализацией вроде разобрались

Сообщение от alvk В целом нормализации вещь хорошая и правильная, но переусердствовать с ней не нужно

Полностью согласна.
Приведу пример: на моем предприятии несколько тысяч работников, помимо должности есть еще категория персонала (общецеховый, оперативный, ремонтный). Я делаю таблицу КАТЕГОРИЯ с перечнем значений. По логике Ameli я должна в эту таблицу добавить поле КОД, которое связать с соответствующим полем в таблице ПЕРСОНАЛ. Я же в таблице ПЕРСОНАЛ сразу делаю поле КАТЕГОРИЯ и подстановку через форму, но сама таблица КАТЕГОРИЯ в связях НЕ УЧАСТВУЕТ. В итоге схема данных получается проще, в ней только основные таблицы.
Собственно вопрос: чем это хуже варианта со связями? Изменения вносить можно, форму при желании тоже можно создать...

0

Сообщение от Pelena чем это хуже варианта со связями?

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

Сообщение от Pelena осмелюсь все-таки еще раз задать вопрос, на который ответа не прозвучало

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

1

Ameli, спасибо. Отлегло... А то я уж переделывать собралась

0

Сообщение от Pelena Я же в таблице ПЕРСОНАЛ сразу делаю поле КАТЕГОРИЯ и подстановку через форму, но сама таблица КАТЕГОРИЯ в связях НЕ УЧАСТВУЕТ. В итоге схема данных получается проще, в ней только основные таблицы. Собственно вопрос: чем это хуже варианта со связями? Изменения вносить можно, форму при желании тоже можно создать...

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

3

Как я понял, в поле КАТЕГОРИЯ хранится не текстовое значение, а код. Сами текстовые значения хранятся в отдельной таблице. Просто эта таблица не связана с таблицей ПЕРСОНАЛ.

0

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

Поменялось одно из слов "Да" и "Нет"? Если уж вы решили передёргивать, то я тоже буду.

0

Сообщение от Михайло Как я понял, в поле КАТЕГОРИЯ хранится не текстовое значение, а код. Сами текстовые значения хранятся в отдельной таблице. Просто эта таблица не связана с таблицей ПЕРСОНАЛ.

Я же понял с точностью до наоборот. Есть справочник Категорий, в котором хранятся только текстовые значения (коды отсутствуют). В связанных таблицах в таком случае, само-собой хранятся также текстовые значения. Вот изначальный вопрос

Сообщение от Pelena Я не понимаю, зачем создавать такое количество таблиц с двумя полями типа КОД и НАЗВАНИЕ, почему нельзя НАЗВАНИЕ сразу поместить в связанную таблицу, особенно если оно состоит из одного слова?

Т.е. иными словами вопрос Pelena сводится к вопросу об использовании естественных ключей.
Чуть позже Pelena начала сомневаться в целесообразности наличия связей в схеме данных по естественным первичному и внешнему ключам.
Если я не прав, то пусть Pelenа меня поправит.

Добавлено через 7 минут

Сообщение от alvk Поменялось одно из слов "Да" и "Нет"? Если уж вы решили передёргивать, то я тоже буду.

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

0

Сообщение от minob понял, о чем вы говорите.

А что же тут непонятного? Допустим у вас автопарк, вы учитываете к примеру движение автобусов, в каждом автобусе у вас на текущий момент может быть только две единицы штата - водитель и кондуктор. По вашему мнению нужна таблица с ними и код в таблице фактов.
По моему мнению в таблице фактов может вполне присутствовать наименование единицы, ибо в обзримом будущем не предвидится, чтобы водитель стал называться "водилой" скажем. Но, если вдруг, кому-то что-то и правда стукнет - update 2 минуты и всё.
Источник поля со списком на форме - сгруппированное поле из таблицы.
Так?

1

Сообщение от minob Есть справочник Категорий, в котором хранятся только текстовые значения

Да, именно текстовые

Сообщение от minob пришло ЦУ изменить наименование какой-то категории

Для категорий это вряд ли, но мысль понятна. Если есть вероятность изменений, то её надо предусмотреть

Сообщение от minob указав каскадное обновление связанных полей

Каскадное обновление не всегда требуется при изменении значения в справочнике (если абстрагироваться от категорий)
То есть опять-таки все зависит от конкретного справочника

0

Сообщение от alvk Допустим у вас автопарк, вы учитываете к примеру движение автобусов, в каждом автобусе у вас на текущий момент может быть только две единицы штата - водитель и кондуктор. По вашему мнению нужна таблица с ними и код в таблице фактов. По моему мнению в таблице фактов может вполне присутствовать наименование единицы, ибо в обзримом будущем не предвидится, чтобы водитель стал называться "водилой" скажем. Но, если вдруг, кому-то что-то и правда стукнет - update 2 минуты и всё.

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

Сообщение от alvk А что же тут непонятного?

Ну вот, когда захотите, то можете и без тумана обходиться.

1

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

в следующем веке.

0

Сообщение от Pelena Каскадное обновление не всегда требуется при изменении значения в справочнике (если абстрагироваться от категорий)

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

Добавлено через 3 минуты

Сообщение от alvk в следующем веке.

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

0

стиль, содержание СТАТЬИ и дискуссии никакого отношения к начинающим не имеют
для начинающих нормальные формы - это то же, что космогонические гипотезы и общая теория относительности для пятикласника.
Мне думается, что стиль статьи должен быть похож на стиль Аленовой Н. изложения материала по хтмл (http://postroika.ru/), т.е для "чайников" с последующим развитием содержания статьи и переходом к более сложным вещам.

0

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

Структурных надеюсь?

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

Тогда им нечего делать здесь. Если первокласник не выучил азбуку, то во втором классе ему делать нечего. К тому же всё уже разжёвано так, что и вправду какой-нибудь шестиклашка всё может освоить.

0

Сообщение от alvk Структурных надеюсь?

Подловили. Имелись ввиду изменения значений поля справочника, которые обсуждаются.

0

Сообщение от В.В.С. стиль, содержание СТАТЬИ и дискуссии никакого отношения к начинающим не имеют

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

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

т.е. с объяснениями.
По поводу содержания: посмотрим правде в глаза: большинство задающих вопросы на нашем форуме - студенты. А им как раз надо знать теорию, т.е. нормальные формы, ER-диаграммы и т.д. Статья направлена на большинство, т.е. на них.
По поводу дискуссий: а вот дискуссии как раз не для начинающих, а для продвинутых пользователей, чтобы совместными усилиями создать материал для начинающих. Здесь каждый может высказать свое мнение

2

Сообщение от minob Подловили. Имелись ввиду изменения значений поля справочника, которые обсуждаются.

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

0

Сообщение от alvk По моему мнению в таблице фактов может вполне присутствовать наименование единицы, ибо в обзримом будущем не предвидится, чтобы водитель стал называться "водилой" скажем. Но, если вдруг, кому-то что-то и правда стукнет - update 2 минуты и всё. Источник поля со списком на форме - сгруппированное поле из таблицы. Так?

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

2

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

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

0