Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Структура БД "Таблица1->Таблица2<-Таблица1"

263
23 октября 2006 года
koltaviy
816 / / 16.12.2004
Ситуация следующая:
Существуют операции, по которым одно предприятие перечисляет денежную сумму другому предприятию.
Таблицы:
COMPANIES (ID, Name);
OPERATIONS (ID, Who_Companies_ID, Whom_Companies_ID, Sum).
Надеюсь, понятно че и с чем связано.. Но это же некорректно!!..
Подскажите, как организовать БД правильно..
8
23 октября 2006 года
mfender
3.5K / / 15.06.2005
С одной стороны всё достаточно правильно в простейшем случае.
Может вопрос пошире открыть: что кажется некорректным?
337
23 октября 2006 года
shine
719 / / 09.06.2006
Помоему, все очень даже красиво сделано. А что тебя не устраивает? Что именно "некорректно"?
263
23 октября 2006 года
koltaviy
816 / / 16.12.2004
[QUOTE=mfender]С одной стороны всё достаточно правильно в простейшем случае.
Может вопрос пошире открыть: что кажется некорректным?[/QUOTE]
Некорректным кажется то, что таблицы связаны двумя связями:
1. COMPANIES.ID - OPERATIONS.Who_Companies_ID
2. COMPANIES.ID - OPERATIONS.Whom_Companies_ID
А для сохранения целостности данных связь между двумя таблицами должна быть только одна.
Работаю в CBuilder'е, но тот же самый MS Access ругается при соединении таким образом в схеме данных.. Говорит, что связь уже существует, а потом создает в схеме данных(не в списке таблиц) копию таблицы COMPANIES - COMPANIES_1.
Это в простейшем случае..
А если допустить еще, что в таблице COMPANIES существует поле City_ID, в котором хранится ID из таблицы CITIES, то в схеме данных вообще творится полный беспредел: созданная копия COMPANIES_1 уже не имеет связи с таблицей CITIES, а если ее создать, то после "переоткрытия" схемы данных у таблицы CITIES тоже появляется копия - CITIES_1, связанная с таблицей COMPANIES_1..
385
23 октября 2006 года
SomewherSomehow
477 / / 25.07.2004
Все корректно с точки зрения структуры БД. По крайней мере я бы сделал точно так же. Что касается акцессовских заморочек - на то он и акцесс сделан через одно место, да простят меня его любители и фанаты =)) Сделай так:
Открой схему данных.
Удали все связи которые есть между COMPANIES и OPERATIONS.
Создай новую связь таким образом: перетащи мышкой питрограммку поля ИД с таблицы COMPANIES в таблицу OPERATIONS, появится окно к котором будет предложено выбрать поля. По умолчанию там будет одна строчка - COMPANIES.ID - OPERATIONS.Who_Companies_ID, в том же окне перейди на строчку ниже и там уже выбери в одном столбце соответсвенно опять COMPANIES.ID а в другом OPERATIONS.Whom_Companies_ID. Все будет ок, будет создана связь двух полей одной таблицы с полем другой, без всяких дубликатов и прочего.
8
23 октября 2006 года
mfender
3.5K / / 15.06.2005
[quote=koltaviy]Некорректным кажется то, что таблицы связаны двумя связями:[/quote]
Но-но, а как же вообще связи "один-ко-многим" и "многие-ко-многим" с точки зрения корректности? Нет-нет, тут всё правильно даже с точки зрения целостности. Целостность может подвергаться опасности только если по полям OPERATIONS.Who_Companies_ID и OPERATIONS.Whom_Companies_ID сделать ключ UNIQUE. Вот этто действительно чревато неприятностями...
263
23 октября 2006 года
koltaviy
816 / / 16.12.2004
To mfender:
При чем тут вообще связи "один-ко-многим" и "многие-ко-многим"..
В плане, данные таблиц и так связаны по отношению "один-ко-многим" - это и так понятно.. А отношение "многие-ко-многим", насколько я знаю, в реляционных БД могут быть реализованы с помощью введения дополнительной таблицы.. К примеру:
МАГАЗИНЫ: Код, Название;
ПРОДУКТЫ: Код, Название;
ПРОДУКТЫ_В_МАГАЗИНАХ: Код, Магазины.Код, Продукты.Код.
To SomewherSomehow:
:) Насчет акцесса согласен.. Просто там все наглядно с точки зрения схемы данных..
А теперь поставь галочку "Обеспечить целостность данных" и все получится не так красиво, как ты это описываешь;):
"Приложению 'Microsoft Access' не удается обеспечить целостность данных для этой связи.
Убедитесь, что перенесенные поля являются ключевыми полями или однозначными индексированными полями, и однозначный индекс или ключевое поле заданы правильно. Для создания связи без обеспечения целостности данных снимите соответствующий флажок."
ОБРАТИТЕ ВНИМАНИЕ НА ПОСЛЕДНЕЕ ПРЕДЛОЖЕНИЕ!!
8
24 октября 2006 года
mfender
3.5K / / 15.06.2005
[quote=koltaviy]Убедитесь, что перенесенные поля являются ключевыми полями или однозначными индексированными полями, и однозначный индекс или ключевое поле заданы правильно. Для создания связи без обеспечения целостности данных снимите соответствующий флажок."
ОБРАТИТЕ ВНИМАНИЕ НА ПОСЛЕДНЕЕ ПРЕДЛОЖЕНИЕ!![/quote]
Очевидно, матюкается он на автоинкремент.
263
24 октября 2006 года
koltaviy
816 / / 16.12.2004
"Матюкается" он не на автоинкремент, а на поле типа автоинкремент(счетчик), которое, являясь ключевым полем, задано не однозначно..
Что-то вроде этого.. Короче суть ошибки отражает то, что я вам говорил ранее.. Данная схема связывания некорректна.. И ошибка тут далеко не в Access..
547
24 октября 2006 года
Hydra
488 / / 20.06.2006
Если ацесс и матюкается, то не на структуру БД. Либо не указано что поля ID в обеих таблицах ключесвые, либо с Who_Companies_ID, Whom_Companies_ID какая-то заморочка (им, кста, нужно ограничение чтобы были не нулевые и такой ID существовал), либо еще что.
Данная структура вполне кореектна и БД находится в 3НФ. Никаких циклических зависимостей тут нет. Любой SQL запрос к данной БД будет вполне корректно обработан.
385
24 октября 2006 года
SomewherSomehow
477 / / 25.07.2004
[QUOTE=koltaviy]"Матюкается" он не на автоинкремент, а на поле типа автоинкремент(счетчик), которое, являясь ключевым полем, задано не однозначно..
Что-то вроде этого.. Короче суть ошибки отражает то, что я вам говорил ранее.. Данная схема связывания некорректна.. И ошибка тут далеко не в Access..[/QUOTE]

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

Кстати обрати внимание:
1) что на самом деле таблицы Company_1 нет в списке таблиц и если попытаться построить к ней запрос то база ругнется что такой не знает...(т.е. НЕ создается никакой копии таблицы)
2) Еще момент, если в редакторе схемы данных добавить одну и ту же таблицу несколько раз будут добавляться таблицы соотв.-но Company_1, Company_2, Company_3 и т.д. (опять же никаких копий НЕ создается)
Совокупность этих признаков думаю позволяет сделать след. вывод, редактор схемы данных для отображения каждой связи просто создает новый графический элемент представляющий одну и ту же таблицу...В общем налицо неудобство и убогость...хотя возможно это я ограничен и в силу этого просто не понимаю Высшего смысла действий майкрософт =)
263
25 октября 2006 года
koltaviy
816 / / 16.12.2004
To SomewherSomehow:
Это не "убогость" MS Access виновата - это его чересчур надуманность виновата.. Про то, что никакой таблицы не создается - это я во втором сообщении уже сказал, да она и не может создаваться таким способом.. А то, что создается такая "копия" таблицы - не недостаток, а достоинство Access(так считает сам MS)..Наглядность на лицо!;) Короче каждому свое..
То что нет никакой ошибки меня убедили.. Почему так себя ведет Access тоже объяснили..
Всем thnks..
263
25 октября 2006 года
koltaviy
816 / / 16.12.2004
З.Ы. to Hydra:
Если бы не было указано, что поле ID - ключевое, а поля Who_Companies_ID и Whom_Companies_ID - целые, то связи в схеме данных и не сделаешь в Access..И никакого ограничения им не надо!!!!
ЧТОБЫ СДЕЛАТЬ ЛЮБОЙ SQL ЗАПРОС, ЦЕЛОСТНОСТЬ ДАННЫХ НЕ НУЖНА.. А РЕЧЬ ШЛА ИМЕННО ПРО ЭТО..
547
26 октября 2006 года
Hydra
488 / / 20.06.2006
Вообще-то речь шла как раз про целостность (посмотри свой 4ый пост). Поле ID обязано быть ключевым, и constraint'ы на поля ведомой таблицы (таблица2) устанавливать обязательно, т.к. нарушаеться целостность, о чем Access тебе и сообщает.
Про SQL. Ясен пень, что на целостность ему плевать, но вот что мы получим в результате? А я писал именно про результат, про то что запрос не просто будет обработан, но
Цитата:

Любой SQL запрос к данной БД будет вполне корректно обработан.



P.S. Данная схема связывания практически классическая - книжки читать не пробовал?

263
26 октября 2006 года
koltaviy
816 / / 16.12.2004
[quote=Hydra]Вообще-то речь шла как раз про целостность (посмотри свой 4ый пост). Поле ID обязано быть ключевым..[/quote]
Я тебе и говорю, что если бы поле было не ключевым, то и в схеме данных ничо бы не получилось соединить..
[quote=Hydra] ..и constraint'ы на поля ведомой таблицы (таблица2) устанавливать обязательно, т.к. нарушаеться целостность, о чем Access тебе и сообщает.
[/quote]
"Constraint'ы" для таблицы2 устанавливать необязательно. Поле просто должно быть длинным целым - это единственное требование. И сообщает он совсем о другом. Help читать не пробовал?:)
[quote=Hydra]
Про SQL. Ясен пень, что на целостность ему плевать, но вот что мы получим в результате? А я писал именно про результат, про то что запрос не просто будет обработан, но..
[/quote]
Повторю, вопрос был не в том, отработает ли корректно запрос или нет. Корректная отработка запроса в большинстве случаев зависит только от написанного в запросе. Вопрос был про целостность!! А не про корректную отработку запросов!..
[quote=Hydra]
P.S. Данная схема связывания практически классическая - книжки читать не пробовал?
[/quote]
Про то, что эта классическая схема связывания - верю.. А если начинаешь ссылаться на книжки, то пиши квоты из книжки, где написано, что эта схема действительно классическая.
Спасибо!!Без обид!!
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог