Форум программистов, компьютерный форум, киберфорум
Наши страницы
MS Access
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.67/9: Рейтинг темы: голосов - 9, средняя оценка - 4.67
Barma
7 / 0 / 0
Регистрация: 02.01.2016
Сообщений: 4
1

Правильная организация связей между тремя таблицами

03.01.2016, 01:13. Просмотров 1553. Ответов 69
Метки нет (Все метки)

Есть три таблицы, надо наладить связь так, чтобы потом можно было делать выборку по области назначения по всему каталогу! Но не получается сделать связи, в чем косяк(
0
Миниатюры
Правильная организация связей между тремя таблицами   Правильная организация связей между тремя таблицами   Правильная организация связей между тремя таблицами  

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
03.01.2016, 01:13
Ответы с готовыми решениями:

Создание связей между таблицами
Здравствуйте уважаемые гуру Есть 5 таблиц (база в приложении) 1. Клиент 2....

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

Создание связей между таблицами
1. Запустите базу данных «Фирма». Сотрудники данной организации работают с...

Создание связей между таблицами
Здравствуйте. Помогите мне пожалуйста создать связи между таблицами. Сами...

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

69
Kapytan
129 / 143 / 64
Регистрация: 27.06.2013
Сообщений: 516
09.01.2016, 18:47 21
mobile, я знаю и о суррогатных ключах и об индексах. Меня здесь постоянно хотят расстрелять за то, что я допускаю использование вместо счетчика других полей записи и даже угрожают.
Примеры: номер ГОСТа, дата (если информация ежедневная) - разве они не могут быть суррогатными ключами.
Кстати, в теории SQL понятие суррогатного ключа отсутствует.
Всем успехов!
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 19:00 22
Цитата Сообщение от Вячеслав Я Посмотреть сообщение
Можно сделать две одинаковые записи, но если у них будут разные ключевые поля, которые как таковые не несут информации, то они уже и разные;
Ну так это как раз и есть самая отвратительная ситуация, которая и была приведена в качестве примера "как не должно быть".

Цитата Сообщение от Вячеслав Я Посмотреть сообщение
может быть просто числом, но однажды Вы устанете искать, то самое число, которое не введено для работы.
Буквально двумя постами выше мы уже договорились, что используем не счетчик, а число, только в том случае, если это число представляет собой естественный ключ. Т.е. это однозачно идентифицирующий сущность атрибут, который у каждой сущности УЖЕ ЕСТЬ. Т.е. его искать не нужно.

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

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

Добавлено через 7 минут
Цитата Сообщение от Kapytan Посмотреть сообщение
Примеры: номер ГОСТа, дата (если информация ежедневная) - разве они не могут быть суррогатными ключами.
На мой вкус, дата, выраженная длинным целым числом (CLng(Дата)) - весьма хороший естественный ключ, и я никогда не заменяю такой ключ суррогатным (счетчик).

А вот с номером ГОСТа я уже не согласна. Это все-таки строка, и достаточно длинная, чтобы индесации, сортировки и поиски по ней стали медленными. Тут для создания суррогатного ключа прямые показания.
0
ltv_1953
Эксперт MS Access
12851 / 5829 / 1118
Регистрация: 21.06.2012
Сообщений: 10,496
09.01.2016, 19:20 23
Цитата Сообщение от texnik-san Посмотреть сообщение
На мой вкус, дата, выраженная длинным целым числом (CLng(Дата)) - весьма хороший естественный ключ, и я никогда не заменяю такой ключ суррогатным (счетчик).
Пример с банком удачнее, код вряд ли может меняться (не будет каскадных обновлений), а вот с датой это не так.
А в общем случае все зависит от конкретной базы. Например, обычно не используют для связей составной ключ, а создают в основной таблице суррогатный - счетчик. Но если в подчиненной таблице для быстродействия нужен Seek по составному индексу, включающему поля основной, то приходится делать связь по составному ключу.
1
Kapytan
129 / 143 / 64
Регистрация: 27.06.2013
Сообщений: 516
09.01.2016, 20:11 24
Цитата Сообщение от texnik-san Посмотреть сообщение
А вот с номером ГОСТа я уже не согласна. Это все-таки строка, и достаточно длинная, чтобы индесации, сортировки и поиски по ней стали медленными.
Это интересный вопрос. А насколько увеличатся затраты времени на обработку и объемы занимаемой памяти ПК?
Хотелось бы услышать в ответ хотя бы очень приблизительные цифры.
Это не возражение с моей стороны, а желание знать истину.
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 21:03 25
Цитата Сообщение от ltv_1953 Посмотреть сообщение
Но если в подчиненной таблице для быстродействия нужен Seek по составному индексу, включающему поля основной, то приходится делать связь по составному ключу.
А можно пример кода, как вообще делается Seek по составному ключу? Не умею.

Добавлено через 48 минут
Цитата Сообщение от Kapytan Посмотреть сообщение
Это интересный вопрос. А насколько увеличатся затраты времени на обработку и объемы занимаемой памяти ПК?
Хотелось бы услышать в ответ хотя бы очень приблизительные цифры.
Это не возражение с моей стороны, а желание знать истину.
На обработку - считайте, что сравнение двух чисел это одна операция, а сравнение двух строк - это в худшем случае столько операций, сколько в меньшей из них букв (на самом деле зависит еще от установленного способа сравнения: побитовое сравнение все же быстрее, но, всилу специфики данных, в Access его использут редко, а побуквенные языково-зависимые - без различения строчных и прописных букв, с яызково-зависимым порядком сортировки - медленнее или гораздо медленнее). Так что скорость работы с текстовыми строками ВСЕГДА ниже, чем с числами.

Вот относительно размера - тут не все так однозначно.

Оговорюсь, что дальнейшие вычисления могут быть неточными, т.к. я, к своему стыду, не знаю, какой в точности размер занимает сейчас 1 символ в строчном типе данных в MS Access. По старинке привыкла считать, что по занимаемому месту один символ = байт, строка из 2 символов = целое, а длинное целое - по длине как 4 символа. И мы помним, что в Access все строки переменной длины, т.е. содержат еще и символ конца строки.

Допустим, в главной таблице стественный ключ - строка длины А. И, скажем, на каждую строку главной таблицы приходится в среднем М зависимых.

Тогда при текстовом ключе затраты места на одну запись в главой таблице равны (А+1) байт, а во второстепенной (А+1)*М байт.

В случае использования суррогатного ключа типа "длинное целое" затраты места в главной таблице увеличатся на 4 байта и станут (А+5) байт, зато во второстепенной - могут заметно снизиться, т.к. равны всего-то 4*М.

Т.е. при длине строки всего-то 5 букв экономия проявляется уже на единственной зависимой записи ))) И будет тем заметнее, чем больше записей в зависмой таблице.

А при длине строки <4 символов экономии места почти нет. Но есть скорость сравнения (см. выше).
0
mobile
Эксперт MS Access
22936 / 13007 / 2694
Регистрация: 28.04.2012
Сообщений: 14,239
09.01.2016, 21:16 26
Цитата Сообщение от Kapytan Посмотреть сообщение
А насколько увеличатся затраты времени на обработку и объемы занимаемой памяти ПК?
Индекс это дерево со многими ветвями, субветвями, субсубветвями и т.д. и "листьями", где собственно хранится сам индекс. Чем длиннее значение, тем больше промежуточных субветвей. И второе - для числового значения, а в особенности для последовательного натурального ряда чисел, есть очень быстрые алгоритмы обхода дерева, чего нет для произвольного текстового индекса.

Цитата Сообщение от texnik-san Посмотреть сообщение
пример кода, как вообще делается Seek по составному ключу?
Предположим есть таблица tt, где первичный ключ составной: id1 и id2, оба числовые, Long. Ищем значение id1=21 и id2=32
Visual Basic
1
2
3
4
5
set rst = currentdb.openrecordset("tt", dbopentable)
with rst
  .index = "primarykey"
  .Seek "=", 21, 32
end with
1
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 21:23 27
Цитата Сообщение от mobile Посмотреть сообщение
.index = "primarykey"
А можно таким же способом использовать имя другого составного идекса? Или только первичный ключ?

Добавлено через 2 минуты
Цитата Сообщение от texnik-san Посмотреть сообщение
А при длине строки <4 символов экономии места почти нет. Но есть скорость сравнения (см. выше).
Точнее, при длине строки ровно 4 символа экономии места почти нет, а <4 символов - вообще нет.
0
mobile
Эксперт MS Access
22936 / 13007 / 2694
Регистрация: 28.04.2012
Сообщений: 14,239
09.01.2016, 21:33 28
Цитата Сообщение от texnik-san Посмотреть сообщение
А можно таким же способом использовать имя другого составного идекса? Или только первичный ключ?
Догадайтесь сами. До счета 3. Время пошло

Добавлено через 3 минуты
Цитата Сообщение от texnik-san Посмотреть сообщение
не знаю, какой в точности размер занимает сейчас 1 символ в строчном типе данных в MS Access
Зависит от фонта. Не поддерживает юникод - 1 байт, поддерживает - 2 байта.
Цитата Сообщение от texnik-san Посмотреть сообщение
мы помним, что в Access все строки переменной длины, т.е. содержат еще и символ конца строки.
Не хранит. Система вставляет если нужно. Иначе бы не было построчной конкатенации.
1
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 21:35 29
Цитата Сообщение от texnik-san Посмотреть сообщение
А можно таким же способом использовать имя другого составного идекса? Или только первичный ключ?
Все получилось!! Клаасс, так крутейшая же возможность!

Добавлено через 1 минуту
Цитата Сообщение от mobile Посмотреть сообщение
Не хранит. Система вставляет при выводе
А как тогда отличается Null от пустой строки?
0
mobile
Эксперт MS Access
22936 / 13007 / 2694
Регистрация: 28.04.2012
Сообщений: 14,239
09.01.2016, 21:38 30
Видимо пустая строка "" это спец символ
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 21:45 31
Цитата Сообщение от mobile Посмотреть сообщение
Иначе бы не было построчной конкатенации.
По-моему, это как раз "система удаляет, если нужно". Я почти уверена, что как раз хранит.

Вот у SQL сервера есть тип данных "строка фиксированной длины" - там конец строки действительно не хранится. А у всех переменных строк признак (простите, не символ) конца строки обязательно должен быть.

Добавлено через 4 минуты
Цитата Сообщение от mobile Посмотреть сообщение
Зависит от фонта. Не поддерживает юникод - 1 байт, поддерживает - 2 байта.
Т.е. я могу уменьшить объем базы, просто изменив шрифт отображения таблиц?
0
mobile
Эксперт MS Access
22936 / 13007 / 2694
Регистрация: 28.04.2012
Сообщений: 14,239
09.01.2016, 21:53 32
Цитата Сообщение от texnik-san Посмотреть сообщение
Я почти уверена, что как раз хранит.
Зачем?

Цитата Сообщение от texnik-san Посмотреть сообщение
Т.е. я могу уменьшить объем базы, просто изменив шрифт отображения таблиц?
В принципе да. Если не ошибаюсь.
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 22:37 33
Хм. Кто знает, какой из шрифтов Windows не поддерживает юникод?

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

Добавлено через 2 минуты
Цитата Сообщение от mobile Посмотреть сообщение
Зачем?
А как без этого он определяет, где закончилась одна строка и начались следующие данные?
0
mobile
Эксперт MS Access
22936 / 13007 / 2694
Регистрация: 28.04.2012
Сообщений: 14,239
09.01.2016, 22:45 34
Скорее всего я ошибся насчет фонта с юникодом. Видимо юникод поддерживается по умолчанию.

Цитата Сообщение от texnik-san Посмотреть сообщение
А как без этого он определяет, где закончилась одна строка и начались следующие данные?
База данных это не строка. Поля отделяются совсем не так как в текстовом файле. Есть спец.механизмы регулирующие доступ к полям и их расположение. Иначе получим тот же самый текстовый файл без прямого доступа к записям и полям.
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
09.01.2016, 22:49 35
Цитата Сообщение от mobile Посмотреть сообщение
Зависит от фонта. Не поддерживает юникод - 1 байт, поддерживает - 2 байта.
Нагуглить удалось только вот что :

Поле Memo .... До 1 гигабайта символов, для хранения которых требуется 2 гигабайта (2 байта на символ).

Добавлено через 1 минуту
Цитата Сообщение от mobile Посмотреть сообщение
База данных это не строка. Поля отделяются совсем не так как в текстовом файле. Есть спец.механизмы регулирующие доступ к полям и их расположение. Иначе получим тот же самый текстовый файл без прямого доступа к записям.
ОК, приимаю на веру, но хотелось бы и почитать об этом что-нибудь. Интересно до ужаса.
0
Kapytan
129 / 143 / 64
Регистрация: 27.06.2013
Сообщений: 516
10.01.2016, 00:05 36
texnik-san, mobile, спасибо. Честно говоря, я ответ для себя не получил. Но Вас ни в коем случае не обвиняю.
Хотелось бы получить более конкретный ответ. Например, в моей базе "Метрология" (схему, именно схему) я выкладывал. Там большая часть первичных ключей не счетчики. Примерно 40 тыс.записей. Так вот, хотелось бы иметь сравнительный анализ в цифрах.
Второй пример. Недавно была выложена схема "Аэропорт". Там ключи - только счетчики. Хотелось бы тоже получить сравнение в цифрах для варианта "Счетчики" и для варианта "Смысловые ключи".
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
10.01.2016, 01:28 37
Kapytan, ну, я лопатить чужие базы только для ответа на ваш вопрос я точно не буду. Я для себя ответ знаю, ровно в том объеме, в каком он мне нужен; вам же будет убедительней ответ самостоятельно найти.

Поставьте эксперимент с вашей базой, которая "Метрология". Только с той частью, где таблицы.

1) переделайте структуру - сделайте цифровые ключи, измените связи, сравните размер;
2) запустите равноцнные запросы, сравните быстродействие.
0
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
10.01.2016, 21:49 38
В общем, ладно - выдалась свободная минутка, поставила эксперимент. Взяла из одной из старых баз две связанные таблицы и импортировала в чистую базу.

Из обеих таблиц удалила все записи, не имеющие связанных. Посмотрела, что записей осталось маловато, дважды "удвоила" все записи второстепенной таблицы (вставила запросом все из себя в себя). Итого у каждой записи главной таблицы минимум 4 записи в свзянной. Сжала/восстановила.

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

Размер итоговых баз: с ключем типа счетчик 4044 КБ, с текстовым ключом 8192 КБ. Вдвое больше.

Прикладываю обе базы, можете потестировать быстродействие на досуге..
0
Вложения
Тип файла: rar WDK.rar (2.54 Мб, 11 просмотров)
alvk
Эксперт MS Access
5610 / 3504 / 170
Регистрация: 12.08.2011
Сообщений: 8,936
12.01.2016, 09:21 39
Цитата Сообщение от texnik-san Посмотреть сообщение
Счетчик - как раз НЕ обязателен. Если у таблицы есть числовой смысловой ключ - а есть основания думать, что у таблицы Каталог это вполне может быть именно так (на момент создания базы у книжки могут уже иметь кем-то ранее присвоенные каталожные номера) - то нет никакой необходимости перенумеровывать их заново.
Абсолютно не согласен. Если ваш номер каталога изменится, то что вы будете делать? Будет две книги, одна настоящая, а вторая виртуальная в каталоге? Когда проще зайти и поменять номер. Или будем практиковать удаления записей, без которых можно было обойтись?
Основным ключом в таблице должно быть поле с типом счётчик, остальные варианты от лукавого.

Добавлено через 16 минут
Цитата Сообщение от texnik-san Посмотреть сообщение
Например, у меня в стране у каждого банка есть шестициферный код, однозначно идентифицирующий банк. Причем заведомо известно, что в нем ведущая цифра не ноль.
Вот в этом случае да, можно обойтись без счётчика. Есть и другие примеры, например код станции ЖД. Но никогда нельзя использовать в качестве ключа то, что возможно потребуется поменять. БИКи банков меняться не будут точно, а каталожные номера при следующей инвентаризации - легко.
1
texnik-san
шапоклякистка 8-го дня
3630 / 2191 / 389
Регистрация: 26.06.2015
Сообщений: 4,648
Записей в блоге: 1
12.01.2016, 10:34 40
Цитата Сообщение от alvk Посмотреть сообщение
Абсолютно не согласен. Если ваш номер каталога изменится, то что вы будете делать? Будет две книги, одна настоящая, а вторая виртуальная в каталоге? Когда проще зайти и поменять номер.
Не представляю, что может заставить существовавший до создания базы каталожный номер вдруг измениться после создания базы. Кто-то на машине времени слетает в прошлое?

Что еще может привести к изменению каталожного номера? У меня фантазия отказывает.

Составление нового каталога? Это повод добавить в таблицу новое поле "номер в новом каталоге". Потому что составление нового каталога затронет все книги в библиотеке, не только одну.

Замена конкретного экземпляра книги другим? Повод списать старый экземпляр и внести новый в базу, другой экземпляр - это другой экземпляр.

Ну и на невообразимый случай действительного изменения каталожного номера у той же самой киги (повторюсь, мне не удается сочинить обстоятельства, при которых это может произойти, но все-таки) - для чего-то существуют триггеры "каскадное обновление".
0
12.01.2016, 10:34
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
12.01.2016, 10:34

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

Несколько связей между двумя таблицами
Здравствуйте! Дали задание по БД, вот схема Никак не могу сделать несколько...

Программная реализация связей между таблицами
Здравствуйте подскажите как программно разорвать / создать связь между двумя...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
40
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru