Как наладить связи в бд?

Question

[famsssss]

Я понимаю как работает бд, НО! Я сломала голову пытаясь установить связи в бд, что мне предстоит сделать. Ничего общего не нашла. а в ручную прописывать айди это гиблое дело: будет по 6 тыс записей в каждой таблице. Остановилась на создании вьюхи где собирается одна единая таблица из всех имеющихся. Идеал работы-у нас есть файлы, мы их БЕЗ редактирования импортируем в бд и вуаля все подтягивается в общую солянку.

Comments

[Ипатьев]

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

И почему вы каждый вопрос задаете с нового аккаунта?

[freeExec]

Я то же мало что понял.
Единственное, что вам стоит узнать, что первичный ключ может состоять из нескольких колонок, поэтому проблема с ISNN решаема.

[Ипатьев]

вы можете хотя бы внятно описать, как соотносятся iddn_vak, issn_r и issn_e? Это один и тот же номер или разные?
Вам нужны все, или только один?

[famsssss]

Ипатьев, issn_vak, isnn_r, issn_b одинаковые. Так же issn_e и eiisn тоже одинаковые. По сути жто идентификатор каждого журнала. Но я не могу создать связь один к одному по этому значению, т.к в одной таблице журнал может быть повторен несколько раз. в итоговой таблице нужен только один issn_vak и issn_e

[famsssss]

freeExec, не совсем понимаю,как мне это поможет. я хочу чтобы создать в первой таблице ключ. но мне программа не даст это сделать т.к. он не является идентификатором, хоть и у каждого имени свой. А если буду делать имя+issn , во-первых ключ по тексту звучит плохо, во вторых они повторяются все равно

[famsssss]

Ипатьев, моя проблема в том что я не могу сделать связи таблиц. всегда связывала айдишниками и все было прекрасно, думала свяжу тут по issn, но не тут то было! т.к он повторяется то теряет свою уникальность и уникальных значений в таблице не остается. вот и делала view

[Ипатьев]

у вас должна быть одна основная таблица, в которой issn уникален.
В остальных это не обязательно
есть такая?

[famsssss]

Ипатьев, на данный момент картина такая:

почему-то в postgresSQL не могу сделать связ 1 к 1, обошла тем, что поставила ограничение уникальности столбцу в самой таблице (кроме vak, там они повторяются)

Вопрос: как подвязать таблицу cat? она совпадает только name cat, но это текст, думаю будет не оптимально.
Таблицу spec скорее всего удалю

[Ипатьев]

еще раз:
в какой таблице issn уникален? есть такая?

[famsssss]

Ипатьев, да, я создала доп. таблицу journals, там он primery key, т.е. уже уникален, в таблице mbd, rinz задала unique для этого столбца, там получится связь 1 к 1, связь к vak 1-ко многим

Answer 1

[mayton2019]

famsssss это ETL с нормализацией. Задача - типичная.
У тебя должен быть примерно такой план действий.

1) Таблицы vak, ring, mdb, cat, spec нужно загрузить в БД как есть. В денормализованном виде. Если они лежат в excel - то сохранить их как CSV формат. Далее дело техники. Можете задать другой вопрос в qna по поводу того как их грузить.

2) Надо нарисовать реляционную модель. Это примерно то что ты рисуешь в картинке но нужно рисовать от сущности-связи а не от того какие файлы даны. Например есть сущность ISNN. У нее есть какие-то атрибуты. Они возможно опциональные. Но они должны быть перечислены. Далее - другие сущности. Потом определяем связи между ними. Например если многим spec соотвествует один ISNN - то тип связи будет многие к одному. Бывает такое что между двумя сущностями связи многие-ко-многим. Как прямоугольная матрица где по горизонтали одна сущность а по вертикали - другая и на пересечении стоит YES когда связь в наличии. Это тоже можно. Это делается через промежуточную таблицу. Связи бывают рекурсивные (таблица может указывать сама на себя). И в РМ могут быть циклы и петли. Это тоже допускается. Просто в этом случае между сущностями будут несколько вариантов как их джойнить и все варианты верны.

3) После того как Реляционная Модель (РМ) определена - в нее можно загружать данные. Можно грузить через INSERT/UPDATE/MERGE. И если возможностей не хватит то можно брать хранимые процедуры на Postgres. Но обычно мне хватало и SQL. В крайнем случае можно брать языки типа Python, Ruby e.t.c. если например доменная модель ооооочень сложная и надо какие-то делать неочевидные поиски по коллекциям или работать с JSON/XML но у тебя вроде все атомарно и лежит просто в ячейках. Должно хватить SQL.

4) Последняя таблица izdanya - по смыслу является отчетом из основной модели. Я настаиваю именно на таком подходе. Физически - это может быть view или таблица неважно. Главное что она - вторична по отношению к модели.