Структура БД

← →
Германн © (2010-12-13 02:26) [0]

Прошу помощи в формировании «сложной» структуры хранения данных. Вопрос скорее к тем, кто имеет опыт в работе с БД, хотя никакой СУБД у меня нет
Данные:
1. Есть набор железок. Для этого набора главными параметрами являются идентификатор и количество датчиков. Количество датчиков имеет ограниченное множество. Для простоты, скажем, 1 и 2.
2. Есть набор объектов, где эти датчики задействованы. Но есть несколько типов объектов (для простоты скажем 1, 2, 3 и 4). Для одних требуется все ресурсы(датчики) железяки, для других только часть.
Теперь сам вопрос. Как лучше организовать и связать эти «табличные структуры», чтобы обеспечить наиболее элегантный, но в то же время «минимальноглючный» доступ к ним?
В интерфейсе ПО пользователь может видеть только эти два набора. Суть «датчиков» от него скрыта чтобы он не ломал голову. Он купил железяки и купил(в данном случае получил бесплатно в придачу) ПО.

← →
Юрий Зотов © (2010-12-13 02:58) [1]

Что-то типа этого:

Таблица_железяк
ID (первичный ключ)
Название_для_юзерского_интерфейса
Количество_датчиков
Другие_поля_если_требуются

Таблица_типов_объектов
ID (первичный ключ)
Название_для_юзерского_интерфейса
Другие_поля_если_требуются

Таблица_связи_железяк_с_типами_ объектов_многие_ко_многим
ID_объекта (первичный ключ) - ссылка на таблицу типов объектов
ID_железяки (первичный ключ) - ссылка на таблицу железяк
Количество_требуемых_дачиков
Другие_поля_если_требуются

← →
Юрий Зотов © (2010-12-13 03:22) [2]

Если каждый тип объектов требует строго определенную железяку, то можно сделать проще. Третья таблица будет не нужна, а вторая такая:

Таблица_типов_объектов
ID (первичный ключ)
Название_для_юзерского_интерфейса
ID_железяки - ссылка на таблицу железяк
Количество_требуемых_дачиков
Другие_поля_если_требуются

← →
Германн © (2010-12-13 03:35) [3]

> Юрий Зотов © (13.12.10 02:58) [1]
>
> Что-то типа этого:
>

> Таблица_связи_железяк_с_типами_ объектов_многие_ко_многим

Спасибо, Юра.
Вот только с третьей таблицей у меня до сих пор непонятки. С учетом того, что часть объектов связана не с самой железякой, а с датчиком. (Связь "многие ко многим" я вроде умел создавать).
Теоретически можно таблицу "железяк" заменить на таблицу "датчиков". Но для интерфейса пользователя тогда возникнут проблемы.

← →
Германн © (2010-12-13 03:40) [4]

> Юрий Зотов © (13.12.10 03:22) [2]
>
> Если каждый тип объектов требует строго определенную железяку

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

← →
Германн © (2010-12-13 03:53) [5]

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

← →
Юрий Зотов © (2010-12-13 04:05) [6]

Датчики разные или одинаковые?

← →
Германн © (2010-12-13 04:15) [7]

> Юрий Зотов © (13.12.10 04:05) [6]
>
> Датчики разные или одинаковые?
>

Одинаковые.
Если бы они были разные - я бы сразу повесился бы в болоте, предварительно выстрелив в себя из дробовика!
:)

← →
Германн © (2010-12-13 04:31) [8]

Может мои вопросы и ответы были весьма "сумбурными".
Но это так и было.
Хочется сделать красиво/элегантно. А не получается.
(Как мне кажется).

← →
Вариант (2010-12-13 06:17) [9]

Таблица объекты с реквизитами объекта.
Таблица контроллер (модуль железяка) с реквизитами типа контроллера и прочим.

Вариант первый - один датчик только на одном объекте
Таблица датчики
- реквизиты датчика + ID Контроллера + ID объекта на котором установлен датчик

Вариант второй - один датчик может обслуживать общую зону двух или более объектов -
Таблица датчики
- реквизиты датчика + ID Контроллера
Таблица связи датчик - объект, в которой хранятся ID датчика+ID Объекта.

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

Для того, что бы связать объект с контроллером, надо связать его через таблицу датчиков. Во втором варианте правда получится связь (запрос) длиннее: объект -> таблица связи с датчиками -> датчики -> контроллер.

← →
Ega23 © (2010-12-13 08:12) [10]

> Но как при этом избежать "дублирования" данных, если мне
> "хочется" оставить таблицу железок?

Это нормально.

Таблица_Железяк
ID_Железки
Название
.....

Таблица датчиков
ID датчика
Название

Cross-таблица датчиков в железе
ID - счётчик
(
ID железки
ID датчика
) каждое вторичный ключ, на составное поле накладываем unique index

Таблица типов объектов
ID типа
Название
.....

Таблица объектов
ID объекта
ID типа (FK)
Название
......

Cross-таблица железок в объекте
ID (счётчик)
(
ID железки
ID объекта
) также оба FK, также unique index

Я бы как-то так сделал.

← →
Anatoly Podgoretsky © (2010-12-13 08:48) [11]

> Германн (13.12.2010 04:15:07) [7]

Два раза, из одноствольного.

← →
Германн © (2010-12-13 13:34) [12]

> Ega23 © (13.12.10 08:12) [10]
>
...
> Это нормально.
...
> Я бы как-то так сделал.

Да. Наверно что-то подобное буду городить. Спасибо.

← →
YurikGL © (2010-12-13 21:53) [13]

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

Тогда структура БД должна выглядеть так.

Таблица_железки
Id_железки:счетчик
Id_ТипЖелезки:внешний ключ (существует так же таблица типов железок, её описывать не будем)

Таблица объектов
Id_объекта:счетчик
Id_ТипОбъекта:внешний ключ (существует так же таблица типов объектов, её описывать не будем)

Таблица датчиков
Id_датчика:счетчик
Id_ТипДатчика:внешний ключ (существует так же таблица типов датчиков, её описывать не будем)
Id_Железки: внешний ключ (к какой железке прицеплен датчик)
Id_Объекта: внешний ключ (на каком объекте установлин датчик)

В общем пришло некое понимание. Вроде как получается сохранение данных всего в двух типизированных файлах. Файл со списком железяк и файл со списком объектов.
Хотя и есть пока неуверенность в правильности решения, но процесс пошел.
Спасибо Юрий, Олег и Юрик!
Отдельное спасибо Анатолию за моральную поддержку бодрости духа!

За моральностью приходи еще, у меня еще есть и пулемет.

> Германн © (13.12.10 02:26)
>
> Прошу помощи в формировании «сложной» структуры хранения
> данных. Вопрос скорее к тем, кто имеет опыт в работе с БД,
> хотя никакой СУБД у меня нет
>

Да уж лучше бы мне было попасть под пулемёт АП! Хоть тогда бы не мучился. :(

Сроки горят, народ негодует, а я изобретаю один велосипед за другим. :(

Ты бы эта.. нормальное ТЗ нарисовал бы. Хотя бы в общих чертах :)

Наверно эта нет

> Германн © (14.12.10 01:30) [14]
>
> В общем пришло некое понимание. Вроде как получается сохранение
> данных всего в двух типизированных файлах.

Я бы access взял.

Структура БД Найти похожие ветки