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

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

3

очень помогает если структура выполнена на языке UML. Это дает в короткий срок создать и проверить всю структуру сразу и если нужно внести изменения.

0

https://www.cyberforum.ru/atta... 1328068610

Вот третья картинка. Там в квадратиках что-то написано, но совершенно не читается.

Что такое Бойс-Кодд? Я просто не знаю, а в статье есть.

Тема нужная. Полезная. Огромное спасибо.
Буду свою базу переделывать под "как надо".

Если что в голове еще всплывет, то дополнительно отпишусь.

0

диаграмму3 вложила еще раз
Нормальная форма Бойса-Кодда названа так в честь Рэя Бойса и Эдгара Кодда, ее описание есть в статье в частности, и в интернете в целом

0

Ameli

Знаю, что вопрос глупый, но всё же.

Все элементы внутри атомарны (неделимы), т.е. не списки

Исходя из первого правила статьи.
Скажите пожалуйста, а уход от этого пункта чем чреват?

/ мне просто или воспользоваться уже найденным (данным) решением своей проблемы или по-новой тему создавать, поскольку многое в логике таблицы меняется тогда.

0

Если имеются в виду поля со списком с множеством значений в 2007 аксессе и выше, то их можно использовать, разделить значения потом в них можно при желании.
Здесь имеется в виду, что в одном поле не должно быть записано через запятую несколько значений, как потом изъять оттуда каждое из них? как потом задействовать в связях это поле?

1

Ameli, добрый день
Хочу уточнить несколько моментов:
1)

Сообщение от Ameli Все элементы внутри атомарны (неделимы), т.е. не списки

А если в одном поле записаны Фамилия Имя Отчество? Я всегда думала, что это тоже не соответствует 1НФ

2) В примере по второй НФ: получается, что две итоговые (нормализованные) таблицы связаны "многие-ко-многим"?

И еще, на мой взгляд, для начинающих было бы полезно дать четкое понятие "первичный ключ", "внешний ключ"

0

Сообщение от Pelena Я всегда думала, что это тоже не соответствует 1НФ

ФИО лучше хранить раздельно, это беспорно, но тем не менее, их совмещение в одно поле не противоречит 1НФ. Здесь имеются в виду, чтоб не было именно списков, если есть список, то его надо вынести в отдельную таблицу.

Сообщение от Pelena 2) В примере по второй НФ: получается, что две итоговые (нормализованные) таблицы связаны "многие-ко-многим"?

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

Сообщение от Pelena для начинающих было бы полезно дать четкое понятие "первичный ключ", "внешний ключ"

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

1

Сообщение от Ameli ФИО лучше хранить раздельно,

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

0

Я придерживаюсь мнения, что, если поле можно разделить на несколько, то лучше разделить.
Может когда-то понадобится, например, Фамилия и инициалы, и придется функциями отделять фамилию из ФИО, потом отделять имя и отчество, брать первые буквы, тогда как в раздельном варианте все намного проще

0

А если не понадобится? Зачем делить? Если это сущность, единое целое? Как номер телефона например, номер телефона тоже делить будем? Вообщем я не согласен с такой постановкой.

0

Ameli, добрый день. Спасибо за Ваше стремление помочь новичкам привести в систему знания.
По поводу статьи ПРИМЕР РАЗРАБОТКИ БД. Я не понимаю, зачем создавать такое количество таблиц с двумя полями типа КОД и НАЗВАНИЕ, почему нельзя НАЗВАНИЕ сразу поместить в связанную таблицу, особенно если оно состоит из одного слова? Это связано с тем, что повторяющиеся текстовые поля увеличивают объём БД? Или есть ещё причины?

0

Сообщение от Pelena есть ещё причины?

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

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

1

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

0

про дни недели никто не говорит. храните их в нужных местах в виде цифр 0-6 (или, что по сути то же самое, как набор значений)

Сообщение от Pelena новичок запутается в ней как муха

для новичков есть простые БД из трех таблиц. а вот в бд посложнее, на каком-то этапе, начинаешь понимать, что денормализация - это зло. я не сильно опытный базостроитель, но ведь проскакивали темы на форуме. конфигурация данных вроде простая, но не заточена под новый требующийся функционал, в дело идут сложные запросы, которые получаются read-only... и понеслось.
само собой, на VBA можно загнуть все что угодно. только дорого это

1

Сообщение от Pelena Или есть ещё причины?

Это делается для гибкости бд, чтоб можно было вносить изменения в подстановки. Те же дни недели могут быть разными, например, воскресенье для каких-нибудь заочников. Вид недели - числитель/знаменатель - может называться по-другому, например, верхняя/нижняя. Про должности и ученые звания я вообще молчу, это ж для примера введены какие-то значения. Пользователи откроют бд и сразу увидят, куда внести изменения, если будут справочники по этим таблицам, а так придется вникать в структуру, искать подстановки

1

То есть это делается с учетом дальнейших изменений, которые могут понадобиться? А также чтобы человек, которому БД досталась "по наследству" мог в ней легко разобраться? Понятно

Сообщение от ironegg денормализация - это зло

В чем денормализация, если вместо повторяющихся кодов будут повторяющиеся слова?

0

Сообщение от Ameli Это делается для гибкости бд, чтоб можно было вносить изменения в подстановки.

Вот что хочу по этому поводу сказать. Для этих целей можно сделать запрос по фактическим данным с группировкой и не надо будет строить отдельные таблицы. С теми же днями недели, для примера, представим ситуацию, что 7 (воскресенье) никогда не используется, в таком случае, при создания источника данных по факту, его и не будет в списке, что кстати является ещё одним плюсом при той же выборке для отчётности. Зачем давать возможность выбора воскресенья, когда по нему нет ни одной записи?
В целом нормализации вещь хорошая и правильная, но переусердствовать с ней не нужно. Всё зависит от конкретной ситуации и конретного техзадания. Контора с пятью сотрудниками не нуждается в справочнике адресов КЛАДР для зарплаты, что не скажешь об организации из 15 000 человек. И т.д. и т.п.
Могу привести примеры когда нормализация - зло, если у кого-то есть желание.

1

Я как и alvk придерживаюсь разумности в подходе к конкретным задачам и ограничениям, а не точного следования всем заповедям Дейта и других гуру. Из личного своего опыта (с начала 80-х годов) изменения простой БД под новые задачи всегда дешевле разработки всеобъемлющих структур для всех будущих и настоящих целей. Желательно было бы показать новичкам на примере КАК это делается, напрмер, на тех же ФИО в одном поле или в разных полях, с таблицей БД или полем со коротким списком.

1

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

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

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

Сообщение от В.В.С. Желательно было бы показать новичкам на примере КАК это делается, напрмер, на тех же ФИО в одном поле или в разных полях, с таблицей БД или полем со коротким списком

Все в одну статью не влепишь, тем более про ФИО в разных полях и в одном поле уже не раз обсуждалось на форуме.

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

1