На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! информация о разделе
user posted imageДанный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ.

Модераторы: Chow, Bas, MIF
Страницы: (4) [1] 2 3 ... Последняя » все  ( Перейти к последнему сообщению )  
> Правильная связь таблиц
    Добрый день.
    Путаюсь при создании правильных структур базы данных (назначение правильно вторичных ключей... бд PostgreSQL).
    Есть три таблицы:
    1. Таблица организаций.
    2. Таблица помещений, которые принадлежат организациям.
    3. Таблица датчиков установленных в этих помещениях.
    Администратор базы данных в программе создает организацию (типа ООО Вымпел в торговом центре). Затем назначает этой организации помещения, которыми она владеет (к примеру, два помещения на первом этаже, одно на втором этаже и т.п.). Затем указывает, в каких помещениях этой организации и сколько в каждом помещении установлено датчиков. В одном помещении, к примеру, один датчик, в другом два и т.д.
    Как связать правильно такие три таблицы? Понятно, что при удалении организации надо автоматом удалить ее следы в других таблицах (помещения и датчики). Помогите, пожалуйста, со структурой таблиц и правильными ключами.
    Спасибо.
      Озаботьтесь поиском и чтением информации по теме "Анализ предметной области". Это - предварительная проработка бизнес-процесса, который будет отображён в базе данных. В ходе анализа выявятся сущности и их атрибуты. В т.ч. атрибуты, которые являются самостоятельными сущностями - именно это и определит связи между таблицами хранения сущностей.

      Удалять ничего не нужно. Это однозначная потеря истории плюс потенциальное разрушение всей БД одним неловким движением мыша. Введите поле актуальности записи (можно логическое, можно дату-время создания этой записи), и работайте только с теми записями, у которых в нём имеется признак валидности (или у которой штамп времени максимален для группы).

      Ключи определяются на стадии анализа - это просто набор однозначно идентифицирующих экземпляр данной сущности атрибутов. В подавляющем большинстве случаев предпочтителен синтетический ключ-счётчик плюс ограничения уникальности.

      Внешние ключи также определяются на стадии анализа - при определении связей с учётом логической целостности и непротиворечивости данных.
        Kitty тут куча вопросов.
        понятно что основные связи это "владеет помещением" и "установлены датчики"
        1. только одна организация владеет одним помешением?
        2. нужно ли знать историю по связям? какие организации владели помещением вчера, год назад? Какие датчики были установлены?
        3. Нужно ли знать план вперед по "овлвдению" помещениями и установке датчиков?
        Ошибки
        1. При удалении организации из здания помещение не может быть удалено
        2. монтаж/демонтаж датчиков в помещении никак не связан (по крайней мере по описанию задачи) с тем, кто владеет данным помещением
        С учетом этих замечаний попробуйте нарисовать ER модель и покажите, что получилось ;)
          Цитата Павел Калугин @
          1. только одна организация владеет одним помешением?

          Как минимум организация-владелец, эксплуатирующая организация (а это далеко не всегда владелец!) и организация-арендатор. И на кого из них "вешать" помещения и датчики - тот ещё вопрос...
          Правильная схема вылезет из анализа и будет совсем даже не элементарной.
            Akina в реальной жизни таки да. Но это же курсовая, которую надо защитить в середине апреля ;)
              Цитата Павел Калугин @
              это же курсовая

              Тогда тем более надо изучить теорию. Чтобы не "плавать" на защите.
                Цитата
                1. только одна организация владеет одним помешением?


                Торговый центр. В нем расположены помещения на разных этажах. Теперь есть организации. Каждая организация владеет разными помещениями. У OOO Вымпел пять помещений на одном этаже. У ООО Пламя три помещения на разных этажах. У ООО Вода одно помещение и т.д.

                Цитата
                22. нужно ли знать историю по связям? какие организации владели помещением вчера, год назад? Какие датчики были установлены?


                Нет не нужо.

                Цитата
                3. Нужно ли знать план вперед по "овлвдению" помещениями и установке датчиков?


                Нет не нужно.

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

                Цитата
                Но это же курсовая, которую надо защитить в середине апреля


                Нет не курсовая, просто построения структур базы вызывает проблемы т.к. воображалки не хватает. :)
                  И на что тут может не хватать воображалки?
                  Организация (1 ко много) Помещение (1 ко много) Датчик

                  Цитата Kitty @
                  связующие ключи

                  Нет такого понятия. Есть первичный ключ (первичный индекс) и просто ключ (индекс), а также особая разновидность ключа (обычно простого) - внешний ключ (индекс и одновременно ссылка на индекс, обычно первичный, в другой таблице, реже в этой же таблице).
                    Вот так примерно?
                    ExpandedWrap disabled
                      CREATE TABLE organizations
                      (
                        ideserial serial NOT NULL,
                        nameorganization character varying(200) NOT NULL,
                        tel1 character varying(20),
                        tel2 character varying(20),
                        prim1 character varying(200),
                        prim2 character varying(200),
                        idorganizations integer,
                        CONSTRAINT idserialorganizations PRIMARY KEY (ideserial),
                        CONSTRAINT nameorganizations UNIQUE (nameorganization)
                      )
                       
                      CREATE TABLE rooms
                      (
                        idserial serial NOT NULL,
                        nameroom character varying(200),
                        nameorganization character varying(200) NOT NULL,
                        idroom integer,
                        idcustomer integer,
                        prim character varying(200),
                        floor character varying(12),
                        CONSTRAINT idrooms PRIMARY KEY (idserial),
                        CONSTRAINT fktoorganizations FOREIGN KEY (nameorganization)
                            REFERENCES organizations (nameorganization) MATCH SIMPLE
                            ON UPDATE CASCADE ON DELETE CASCADE,
                        CONSTRAINT unikname UNIQUE (nameorganization)
                      )
                       
                      CREATE TABLE sensors
                      (
                        idserial serial NOT NULL,
                        nameorganization character varying(200) NOT NULL,
                        id integer NOT NULL,
                        lastdt timestamp without time zone,
                        roomid integer,
                        prim character varying(128),
                        idroom integer,
                        nameroom character varying(200),
                        CONSTRAINT sensorsid PRIMARY KEY (idserial),
                        CONSTRAINT fktorooms FOREIGN KEY (nameorganization)
                            REFERENCES rooms (nameorganization) MATCH SIMPLE
                            ON UPDATE CASCADE ON DELETE CASCADE,
                        CONSTRAINT sensors_nameorganization_key UNIQUE (nameorganization)
                      )
                      Ну если очень примерно - то да. Исключительно в части имён таблиц и формирования первичных и внешних ключей.

                      Хотя я бы предложил не бежать вперёд паровоза, и заняться теорией. Хотя бы чтобы понимать, что эта структура не сильно отвечает 3НФ. Дублирование на каждом шагу, плюс потенция рассогласования данных.

                      Во всяком случае с такой структурой даже курсовую не сдать - это стопудово. А о боевой системе даже речи идти не может.
                      Сообщение отредактировано: Akina -
                        ExpandedWrap disabled
                          Ну если очень примерно - то да.


                        Спасибо.

                        ExpandedWrap disabled
                          Дублирование на каждом шагу, плюс потенция рассогласования данных.


                        Собственно поэтому и обратилась за помощью здесь. :)
                        Подредактируйте, пожалуйста.
                          У меня хрустальный шар в ремонте, а догадываться, что будет записано в какое поле, тупо лень. Уж не поленитесь...
                          А для начала уберите поля, которые есть в таблице на стороне "один", из таблицы на стороне "много".
                          И уберите каскадное удаление - если организация съедет, это не значит, что датчики демонтируют и комнату сломают.
                            Цитата
                            И уберите каскадное удаление - если организация съедет, это не значит, что датчики демонтируют и комнату сломают.


                            Теперь поняла. :)

                            Цитата
                            Уж не поленитесь...


                            Кол-во и название полей еще не определено. Это я просто накидала разных полей для тестирования каскадного удаления. Мне самой надо придумать правильные поля для всех трех таблиц, чтобы было информативно и удобно потом пользоваться.
                            В простом случае можно упростить все до такого:
                            В таблице организаций - только названия организаций. Наверно оно должно быть уникальным?
                            В таблице помещений - только названия помещений/или может уникальный номер помещения (ну и к примеру этаж где это помещение).
                            В таблице датчиков - уникальный серийный номер датчика, в каком он помещении.
                            Теперь в интерфейсе программы надо понимать: организация->ее помещения->ее датчики в этих помещениях. При выборе конкретного помещения знать сколько в нем датчиков и какие это датчики по их номеру.

                            При таком минимальном кол-ве полей, как бы вы организовали?
                            Спасибо.
                            Сообщение отредактировано: Kitty -
                              Цитата Kitty @
                              В таблице организаций - только названия организаций. Наверно оно должно быть уникальным?

                              Сфига бы? Вот пара ИНН+КПП - та уникальна. А одноимённых организаций аки грязи.

                              Цитата Kitty @
                              В таблице помещений - только названия помещений/или может уникальный номер помещения

                              Номер. И для справки - название.

                              Цитата Kitty @
                              Мне самой надо придумать правильные поля для всех трех таблиц, чтобы было информативно и удобно потом пользоваться.

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

                              Цитата Kitty @
                              как бы организовали?

                              Не скажу. Мне пофиг, создадите Вы свою БД или нет. Так что делать её ЗА ВАС, пусть даже эта просьба и высказана в такой форме - не буду.
                              Изучайте. И только потом делайте - кавалерийским наскоком, без теории и понимания, как и почему делать, не получится. Вот с проблемами или непонятками - но совершенно конкретными, - милости просим. Объясним, как нужно, и почему именно так.
                              Ну а коли не хотите изучать, хотите сразу готовую БД - то Вы ошиблись форумом. С таким подходом - во фриланс.
                                Akina сегодня не с той ноги встал...
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0534 ]   [ 16 queries used ]   [ Generated: 28.03.24, 17:19 GMT ]