|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Привет, форумчане! Я недавно начал изучать базы данных и возник вопрос, создаю базу данный для контроля перелетов внутри страны я выделил несколько сущностей: перевозчик, экипаж, самолет, рейс. Пусть пока так. По ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит. Т.е. : organization id (PK) crew id (PK) organization_id(FK) plane id (PK) organization_id(FK) flight id (PK) plane_id(FK) crew_id(FK) some_another_info Но тогда получается что можно добавить в таблицу flight экипаж и самолет из разных организаций, можно ли как-то это организовать, чтобы это физически нельзя было сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2021, 21:03 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
заполнять flight через функцию check тут не вывезет ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2021, 01:10 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
voiteshonok Но тогда получается что можно добавить в таблицу flight экипаж и самолет из разных организаций, можно ли как-то это организовать, чтобы это физически нельзя было сделать? Да. Для этого нужно добавить в таблицу flight поле organization_id и сделать ссылки flight => crew и flight => plane по составным внешним ключам (crew_id, organization_id) и (plane_id, organization_id) соответственно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2021, 01:49 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
voiteshonok, Не все ограничения можно и нужно реализовывать на уровне схемы. Часть лучше делать в коде, который с этой схемой данных работает. В вашем случае я вижу два варианта:
... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2021, 07:38 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Ennor Tiegael Не все ограничения можно и нужно реализовывать на уровне схемы. Часть лучше делать в коде, который с этой схемой данных работает. +++ После того как вы в интерфейсе выберите Перевозчика, по organization_id вы сможете наложить ограничения на выборку из crew и plane (по этому самому organization_id) для составления flight Как-то все забывают, о существовании интерфейса от слова совсем, а на БД пытаются смотреть через призму Экселя... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 17:58 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
vmag Как-то все забывают, о существовании интерфейса от слова совсем К одной базе бывают разные интерфейсы и бывает доступ мимо интерфейса. Если о процедурной обвязке ещё можно говорить как о средстве контроля целостности, то интерфейс как основной инструмент для этого не подходит никак. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:04 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
А в данном случае оно нужно? Боинг ПанАм вполне может пилотироваться экипажем АльКайды. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:08 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
softwarer К одной базе бывают разные интерфейсы нормальные и кривые... softwarer бывает доступ мимо интерфейса для админов, чтоб исправлять косяки кривых интерфейсов... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:11 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
vmag для админов, чтоб исправлять косяки кривых интерфейсов... Слова типа "API" или "сервисы" для Вас незнакомы? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:12 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov А в данном случае оно нужно? Боинг ПанАм вполне может пилотироваться экипажем АльКайды. ну терроризм вряд ли стоит закладывать в ТЗ... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:12 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
softwarer Слова типа "API" или "сервисы" для Вас незнакомы? Знакомы, тоже бывают нормальные и кривые, соответствующие общему ТЗ и нет... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:14 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
vmagну терроризм вряд ли стоит закладывать в ТЗ... Зато фрахт или любой другой вид аренды - вполне таки да. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:24 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, voiteshonok По ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит. Ну, если компания сама наняла пилотов из Аль... в работу, то только это дает смысл вашему посту и не противоречит ТЗ... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:38 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
vmag ... Как-то все забывают, о существовании интерфейса от слова совсем, а на БД пытаются смотреть через призму Экселя... Это по Фрейду оговорка. А softwarer рассказывает вам, что связи между "сущностями" в реляционной бд эквивалентны сущностям. Как "сущности" так и связи между ними представляются объектами одного и того же рода - и те и другие - таблицами-отношениями. crew и plane здесь - это таблицы связей между "сущностями", а не самостоятельные "сущности". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 18:51 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
booby, Я уже в одном посту Вам написал, что для меня Ваш полет мыслей недосягаем... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2021, 19:04 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Ennor Tiegael voiteshonok, Не все ограничения можно и нужно реализовывать на уровне схемы. Часть лучше делать в коде, который с этой схемой данных работает. Все ограничения, которые можно сделать на уровне схемы нужно (крайне желательно) делать на уровне схемы. Любое приложение подвержено ошибкам и не гарантирует непрерывной целостности данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2021, 20:31 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
SQL*Plus, Желательно еще и голову подключать при этом. Если ТС мигрирует неключевой атрибут из двух таблиц, то имеющуюся проблему это решит, но заодно создаст и новую - что делать, когда ограничение авторПо ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит. будет убрано. А оно, скорее всего, будет однажды убрано, потому что в жизни бывает всякое. Я не спорю, что в некоторых предметных областях такое решение будет оправдано, и его никогда не придется переделывать. Просто потому, что данные, нарушающие такой констрейнт, не имеют смысла. В данном случае, лично для меня такое ограничение выглядит искуственным, а это значит, что когда экипаж сляжет с пищевым отравлением за 5 часов до вылета, а лететь надо, то у такой системы возникнут проблемы, которые на пользовательском уровне не решаемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2021, 02:38 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Ennor Tiegael, ежу понятно, что это учебная задача. И в рамках учёбы знать о такой возможности - нужно. А вот выбирать из палитры возможностей наиболее подходящие для конкретных случаев - это уже искусство архитектурных решений. Вещь куда более сложная и для автора явно далеко впереди. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2021, 02:44 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
softwarer, Ну да, я потому и написал в самом начале:авторЕсли это курсач, то можно делать вариант 2 Знать о возможных вариантах - да, безусловно, очень важно. Так сказать, первая ступень. Но имхо, понимание разницы между ними, и последствий выбора - это вторая ступень, а не третья или десятая. Я имею в виду - что бы мы ни написали в этом топике, ТС это все будет полезно. Разумеется, если он сможет это понять :). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2021, 03:22 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Ennor Tiegael, согласен. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2021, 03:52 |
|
проектирование таблиц
|
|||
---|---|---|---|
#18+
Ennor Tiegael SQL*Plus, Желательно еще и голову подключать при этом. Если ТС мигрирует неключевой атрибут из двух таблиц, то имеющуюся проблему это решит, но заодно создаст и новую - что делать, когда ограничение авторПо ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит. будет убрано. А оно, скорее всего, будет однажды убрано, потому что в жизни бывает всякое. Любая модель - это упрощенное представление реально существующей жизненной ситуации. Есть постановка задачи, есть её реализация средствами СУБД и приложения. Декларативные ограничения целостности - это один из способов моделирования ограничений реальной жизни. Жизнь изменяется, поэтому и модель должна изменяться, следуя за жизнью. Было ограничение, что пилоты должны работать в той же компании, которой принадлежит самолет. В соответствии с ним было наложено декларативное ограничение. Ситуация изменилась и теперь самолеты могут пилотировать экипажи из других компаний. Декларативное ограничение необходимо будет отменить. И так далее. Жизнь меняется, модель следует за жизнью. Иногда с отставанием. Если вы хотите предусмотреть, чтобы ваша система могла отражать всё, что бывает в жизни, тогда схема данных должна быть суперуниверсальной. Например, такой: Сущность: ID - идентификатор сущности INFO - информация о сущности (XML / JSON) Связь: ID_1 - идентификатор сущности 1 ID_2 - идентификатор сущности 2 ID_3 - идентификатор сущности 3 ID_4 - идентификатор сущности 4 Всё богатство и разнообразие мира укладываем в две таблицы :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2021, 10:52 |
|
|
start [/forum/topic.php?fid=32&gotonew=1&tid=1539780]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
13ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 191ms |
0 / 0 |