Зачем связывают таблицы?

← →
parovoZZ © (2006-01-09 01:51) [0]

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

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

родительском поле.

Но это какие-то слабенькие доводы в пользу сабжа.
Если не так, то тогда следующая задачка.
Есть две таблицы : Equipments и Objects (даны фрагменты)

Equipments
-------------------------------------------------
Equipment | Object | System |
-------------------------------------------------
| | |

Objects
-------------------------------------------------
Object_ID* | Object | |
-------------------------------------------------
| | |

Поле Object верхней таблицы связано с полем Object_ID (ключевое) нижней.
Так вот, я с помощью запроса

SELECT Object FROM Equipments WHERE System=:prmID

получаю кучу значений поля Object (фактически Object_ID). А вот как теперь по этим значениям

получить сопоставленные им значения из поля Object таблицы Objects? В цикле? А нельзя ли сразу в

SQL-запросе это организовать? Если нет, какой мне торч от того, что эти таблицы связаны. Всё

равно поиск происходит на программном уровне.

← →
ЮЮ © (2006-01-09 03:20) [1]

"Связывать", конечно, можно и на уровне запроса, но здесь приходится уже "гадать на кофейной гуще". Кстати, твоя Objects в этом смысле очень показательна. Ибо по названиям полей не понть какая связь должна быть
Equipments.Object <-> Objects.Object
или
Equipments.Object <-> Objects.ObjectId

>А нельзя ли сразу в SQL-запросе это организовать?
А что мешает?

SELECT *
FROM
Equipments Eq
[LEFT] JOIN Objects Obj ON Eq.Object = Obj.ObjectId
WHERE
System=:prmID

← →
Fay © (2006-01-09 04:25) [2]

2 parovoZZ © (09.01.06 1:51)
> Невозможность удаления информации в подчиненном поле пока есть
> ссылка на него у родителя.
Что такое "подчиненное поле"?
Что такое "ссылка на него у родителя"?

> Невозможность выбора иной, нежели представленной у подчиненного
> поля, информации в родительском поле.
Что такое "информация в родительском поле"?
В чём заключается "выбор" информации?

Вы, похоже, путаете детей с родителями. Это плохо.

> Но это какие-то слабенькие доводы в пользу сабжа
Это вАщЕ хрень какая-то. Что Вы понимаете под словом "связывание"?
Если join, то сказаное в пунктах 1 и 2 не справедливо.
Если reference в виде foreign key, то это же contraint (!), т.е. ограничение. Какие ещё, блин, доводы?

Прочитайте свои книги ещё раз.

> Есть две таблицы : Equipments и Objects (даны фрагменты)
Описывая структуру, используйте DDL - Вас поймут все, кто в состоянии ответить.

> получаю кучу значений поля Object (фактически Object_ID).
Что значит "фактически Object_ID"? У Вас имеется зависимость межжу ключевыми и неключевыми полями?! Фтопку!

> А вот как теперь по этим значениям получить сопоставленные им
> значения из поля Object таблицы Objects? В цикле?
На этот вопрос уже ответил ЮЮ [1]; скажу лиши, что он (вопрос) вызывает недоумение. Бросайте на время писать - ещё не всё прочитано.

← →
parovoZZ © (2006-01-09 11:13) [3]

ВООБЩЕ запутали меня. Есть связка Equipments.Object <-> Objects.Object_ID Эти два поля должны быть обязательно ключевыми? Зачем? Т.е. при изменении (UPDATE) информации в любом из них она изменится в другом? Тогда не понятно, что такое "один ко многим".

А что такое DDL? Мы такого не проходили. А по поводу книг - правильно. Читал ночью и очень бегло. Ну очень было интересно как это всё устроено.

← →
Dioman © (2006-01-09 11:46) [4]

> parovoZZ © (09.01.06 11:13) [3]

RTFM

← →
Fay © (2006-01-09 11:58) [5]

2 parovoZZ © (09.01.06 11:13) [3]
> Эти два поля должны быть обязательно ключевыми?
Только для связи 1 к 1(0).

> Т.е. при изменении (UPDATE) информации в любом из них она изменится в другом?
Только при on update cascade или по просьбе тригера.

> Тогда не понятно, что такое "один ко многим".
Это отношение.

> А что такое DDL
Data definition language

> Мы такого не проходили
В каком полку служили?

← →
parovoZZ © (2006-01-09 16:20) [6]

Супер, с задачкой разобрался. НО

А чем же тогда отличается внешнее связывание от внутреннего? Можете привести пример что может первое и что не может второе?

И всё-таки для чего связывают таблицы при их создании (DataBase Desctop или MSaccess), если они прекрасно связываются при SQL-запросах ?

RTFM ..... это что ещё за зверь.....

← →
Fay © (2006-01-09 16:35) [7]

2 parovoZZ © (09.01.06 16:20) [6]
> RTFM ..... это что ещё за зверь.....
read the f.cking manual

> А чем же тогда отличается внешнее связывание от внутреннего?

RTFM

> И всё-таки для чего связывают таблицы при их создании (DataBase Desctop или MSaccess),
> если они прекрасно связываются при SQL-запросах ?
Бегом в библиотеку!

← →
mr.IL © (2006-01-09 18:07) [8]

2 parovoZZ А может вам это ваще не надо, а?

← →
parovoZZ © (2006-01-10 05:52) [9]

Надо, Федя, надо...

← →
mr.il © (2006-01-10 05:58) [10]

А вы попробуйте это сделать, и увидите результат. Правда я это не делаю.

← →
parovoZZ © (2006-01-10 10:16) [11]

Ну к примеру, берём MSAccess, делаем две таблицы. В поле тип данных с помощью мастера подстановки ссылаемся на ключевое поле из другой таблицы (отношением один ко многим). Зачем? Если при SQL-запросе мне всё равно приходится эти два поля связывать.

← →
Виталий Панасенко (2006-01-10 10:53) [12]

Ты просто путаешь обеспечение целостности данных, с выборкой данных.
Суть такого завязываения, например № карточки (уникальный) человека в поликлиннике. К этому номеру привязаны: ФИО, Адрес, группы учета(гипертония, сахарный диабет и тд). И есть таблица движений(посещений) поликлинники примерно такого вида: дата посещения, № карточки, врач.
Что бы узнать, кто какого врача посещал(когда) ты и соединяешь в запросе на выборку (select № карточки=№ карточки в движении). И чтобы ты это мог делать даже при изменении № карточки в таблице-справочнике организовывается каскадное обновление/удаление данных..
См. http://ord.com.ru/files/book2/

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

ЗЫЖ Почитай про внешние ключи и ваще про реляционную модель.

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

Определение связок
---------------------
"Внутреннее" (этот термин мне кажется не совсем удачным, т.к. совершенно непонятно, внутри ЧЕГО) связывание - это совершенно необходимое средство формализации (описания языком табличных структур) сложных объектов-сущностей, не "укладывающихся" в одну таблицу. Как пример можно привести упомянутую выше лицевую карточку в задачах кадрового учета или в зарплате. Один объект (человек) имеет несколько сложных характеристик, каждая из которых требует как минимум одну собственную таблицу (помесячные начисления-удержания, отметки о приказах о перемещении, информация о льготах и т.д.). Т.е. фактически имеем картотеку, хранящуюся в нескольких (иногда "несколько" исчисляется десятками и даже сотнями) таблицах, логически связанных в одно целое. Если же добавить к этому сложному объекту еще и другие, ссылающиеся на него, например, в ERP-системах, это может быть учет МБП, касса, реализация ГП и пр., то мы получим достаточно сложную, весьма разветвленную сеть ссылок, реализующих "внешнее" связывание.
Обеспечение "прочности" и достоверности всех этих ссылок - одна из наиглавнейший задач любой БД.

Реализация связок.
-------------------
Как упоминалось выше, связки могут быть "внутренние", т.е. описывающие связи разных характеристик одного объекта-сущности, так и "внешие", главное назначение которых-обеспечить причинно-следственную связь между разнородными объектами.
В нормализованных БД принято связи обоих типов выполнять через уникальные идентификаторы, однозначно указывающие на объект-сущность.
Такой механизм делает независимым хранение данных об объекте от собственно самих данных, которые могут изменяться со временем. Изменения любых нативных (естественных, натуральных) характеристик-реквизитов в таком объекте никаким образом не повлияют на его "положение" в общей логической модели данных (ибо не изменится его ID,- то, на что указывают другие объекты, ссылающиеся на меняющейся объект). Реализовать эти связки, говоря обобщенно, можно двумя способами :
1) Бизнес-логика : ввести некие правила в саму БД - foreign, master-detail, etc (для SQL-серверных БД сущеситвует еще куча всяких фич типа триггеров, ХП, функции и т.д.). Заданная таким образом связка жестко ограничивает манипуляцию связанными данными, откуда бы ни шла попытка изменения БД.
2) Логика клиента: никаких ограничений непосредственно в БД не вносится и вся логика программируется собственно в программе. При этом другая программа в этой же БД может делать все, что ей "вздумается", игнорируя "логику" первой программы.

Подгоретский говорит, что идти учится конкретно на программиста не стоит. Так что вот так.

А всё выше сказанное пойду сейчас переваривать. Но я от Вас не отстану. Я такой.

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

Полностью согласен с предыдущим оратором.
1) Азы нужно знать "на зубок".
2) Практику не заменит ничто.

Зачем связывают таблицы? Найти похожие ветки