powered by simpleCommunicator - 2.0.31     © 2024 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / проектирование таблиц
21 сообщений из 21, страница 1 из 1
проектирование таблиц
    #40098471
voiteshonok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Привет, форумчане! Я недавно начал изучать базы данных и возник вопрос, создаю базу данный для контроля перелетов внутри страны
я выделил несколько сущностей: перевозчик, экипаж, самолет, рейс. Пусть пока так. По ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит. Т.е. :
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 экипаж и самолет из разных организаций, можно ли как-то это организовать, чтобы это физически нельзя было сделать?
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098498
заполнять flight через функцию
check тут не вывезет
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098501
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
voiteshonok
Но тогда получается что можно добавить в таблицу flight экипаж и самолет из разных организаций, можно ли как-то это организовать, чтобы это физически нельзя было сделать?

Да. Для этого нужно добавить в таблицу flight поле organization_id и сделать ссылки flight => crew и flight => plane по составным внешним ключам (crew_id, organization_id) и (plane_id, organization_id) соответственно.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098509
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
voiteshonok,

Не все ограничения можно и нужно реализовывать на уровне схемы. Часть лучше делать в коде, который с этой схемой данных работает.

В вашем случае я вижу два варианта:
  • Делать проверку в коде, при вставке / обновлении данных. Это более гибко, потому что, если / когда экипажи начнут водить самолеты других компаний, вам потребуется поменять только код (в данном случае - просто убрать проверку совпадения OrganisationId у борта и у экипажа).
  • Делать, как подсказал softwarer постом выше - внести OrganisationId в ключи борта и экипажа и мигрировать их оба в одно и то же поле в таблице полетов. Вставить некорректные данные будет физически невозможно, но в случае расширения функционала вам придется править и данные, и код (да и схему, в общем-то). Ну и, строго говоря, такой дизайн нарушает НФБК, насколько я понимаю.
Если это курсач, то можно делать вариант 2, но будьте готовы к тому, что вам придется перечислить потенциальные проблемы с его использованием. В реальной жизни, в большинстве случаев я бы так не делал, ибо ТЗ, в отличие от скрижалей, не высечены в камне.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098761
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael
Не все ограничения можно и нужно реализовывать на уровне схемы. Часть лучше делать в коде, который с этой схемой данных работает.

+++

После того как вы в интерфейсе выберите Перевозчика, по organization_id вы сможете наложить ограничения на выборку из crew и plane (по этому самому organization_id) для составления flight

Как-то все забывают, о существовании интерфейса от слова совсем, а на БД пытаются смотреть через призму Экселя...
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098762
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
Как-то все забывают, о существовании интерфейса от слова совсем

К одной базе бывают разные интерфейсы и бывает доступ мимо интерфейса. Если о процедурной обвязке ещё можно говорить как о средстве контроля целостности, то интерфейс как основной инструмент для этого не подходит никак.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098765
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А в данном случае оно нужно? Боинг ПанАм вполне может пилотироваться экипажем
АльКайды.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098767
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
К одной базе бывают разные интерфейсы

нормальные и кривые...
softwarer
бывает доступ мимо интерфейса

для админов, чтоб исправлять косяки кривых интерфейсов...
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098768
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
для админов, чтоб исправлять косяки кривых интерфейсов...

Слова типа "API" или "сервисы" для Вас незнакомы?
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098769
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
А в данном случае оно нужно? Боинг ПанАм вполне может пилотироваться экипажем
АльКайды.


ну терроризм вряд ли стоит закладывать в ТЗ...
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098771
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Слова типа "API" или "сервисы" для Вас незнакомы?

Знакомы, тоже бывают нормальные и кривые, соответствующие общему ТЗ и нет...
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098775
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmagну терроризм вряд ли стоит закладывать в ТЗ...

Зато фрахт или любой другой вид аренды - вполне таки да.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098778
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,
voiteshonok
По ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит.


Ну, если компания сама наняла пилотов из Аль... в работу, то только это дает смысл вашему посту и не противоречит ТЗ...
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098782
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag
...

Как-то все забывают, о существовании интерфейса от слова совсем, а на БД пытаются смотреть через призму Экселя...

Это по Фрейду оговорка.

А softwarer рассказывает вам, что связи между "сущностями" в реляционной бд эквивалентны сущностям.
Как "сущности" так и связи между ними представляются объектами одного и того же рода - и те и другие - таблицами-отношениями.
crew и plane здесь - это таблицы связей между "сущностями", а не самостоятельные "сущности".
...
Рейтинг: 0 / 0
проектирование таблиц
    #40098786
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby,

Я уже в одном посту Вам написал, что для меня Ваш полет мыслей недосягаем...

YouTube Video
...
Рейтинг: 0 / 0
проектирование таблиц
    #40100329
SQL*Plus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael
voiteshonok,

Не все ограничения можно и нужно реализовывать на уровне схемы.
Часть лучше делать в коде, который с этой схемой данных работает.

Все ограничения, которые можно сделать на уровне схемы нужно (крайне желательно) делать на уровне схемы.
Любое приложение подвержено ошибкам и не гарантирует непрерывной целостности данных.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40100361
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SQL*Plus,

Желательно еще и голову подключать при этом. Если ТС мигрирует неключевой атрибут из двух таблиц, то имеющуюся проблему это решит, но заодно создаст и новую - что делать, когда ограничение
авторПо ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит.
будет убрано. А оно, скорее всего, будет однажды убрано, потому что в жизни бывает всякое.

Я не спорю, что в некоторых предметных областях такое решение будет оправдано, и его никогда не придется переделывать. Просто потому, что данные, нарушающие такой констрейнт, не имеют смысла. В данном случае, лично для меня такое ограничение выглядит искуственным, а это значит, что когда экипаж сляжет с пищевым отравлением за 5 часов до вылета, а лететь надо, то у такой системы возникнут проблемы, которые на пользовательском уровне не решаемы.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40100362
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael,

ежу понятно, что это учебная задача. И в рамках учёбы знать о такой возможности - нужно. А вот выбирать из палитры возможностей наиболее подходящие для конкретных случаев - это уже искусство архитектурных решений. Вещь куда более сложная и для автора явно далеко впереди.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40100363
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer,

Ну да, я потому и написал в самом начале:авторЕсли это курсач, то можно делать вариант 2
Знать о возможных вариантах - да, безусловно, очень важно. Так сказать, первая ступень. Но имхо, понимание разницы между ними, и последствий выбора - это вторая ступень, а не третья или десятая.

Я имею в виду - что бы мы ни написали в этом топике, ТС это все будет полезно. Разумеется, если он сможет это понять :).
...
Рейтинг: 0 / 0
проектирование таблиц
    #40100364
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael,

согласен.
...
Рейтинг: 0 / 0
проектирование таблиц
    #40100399
SQL*Plus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael
SQL*Plus,

Желательно еще и голову подключать при этом. Если ТС мигрирует неключевой атрибут из двух таблиц, то имеющуюся проблему это решит, но заодно создаст и новую - что делать, когда ограничение
авторПо ТЗ экипаж может водить самолет только той компании, к которой сам принадлежит.

будет убрано. А оно, скорее всего, будет однажды убрано, потому что в жизни бывает всякое.

Любая модель - это упрощенное представление реально существующей жизненной ситуации.

Есть постановка задачи, есть её реализация средствами СУБД и приложения.
Декларативные ограничения целостности - это один из способов моделирования ограничений реальной жизни.
Жизнь изменяется, поэтому и модель должна изменяться, следуя за жизнью.

Было ограничение, что пилоты должны работать в той же компании, которой принадлежит самолет.
В соответствии с ним было наложено декларативное ограничение.

Ситуация изменилась и теперь самолеты могут пилотировать экипажи из других компаний.
Декларативное ограничение необходимо будет отменить.

И так далее.
Жизнь меняется, модель следует за жизнью. Иногда с отставанием.

Если вы хотите предусмотреть, чтобы ваша система могла отражать всё,
что бывает в жизни, тогда схема данных должна быть суперуниверсальной.

Например, такой:

Сущность:
ID - идентификатор сущности
INFO - информация о сущности (XML / JSON)

Связь:
ID_1 - идентификатор сущности 1
ID_2 - идентификатор сущности 2
ID_3 - идентификатор сущности 3
ID_4 - идентификатор сущности 4

Всё богатство и разнообразие мира укладываем в две таблицы :-)
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / проектирование таблиц
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]