Комментарии 14
Допустим, что мир состоит из сущностей.
А если не допустим? Ну да ладно, старый вопрос и множество попыток объяснить, зачем объектам и субъектам материального мира придумали такое обобщенное название.
Но беда в другом - в подобных графических схемах нет еще одного элемента - времени (временнОй оси). А как ни крути, время и течение времени помимо нашей воли беспардонно наличествует, и без него оценивать манипуляции с объектами и субъектами материи - бессмысленно.
Так или иначе, имеются состояния материи и информации в каждый момент времени (длительность которого мы на текущем этапе развития технологий можем атомизировать). Слова, описывающие дифференциальную плавность событий - "прогресс", "развитие" можно забыть - они для красоты слова, пока что мы фактически наблюдаем только периодические изменения материи и информации.
Кстати базы данных для этого идеально подходят, так как фиксируют свойства и события с частотой, ограниченной скоростью движка базы данных (а также дисков, памяти и проч.).
Но отсутствие в подобных использованной в данной статье моделях временнОй оси требует создания триггеров, стопов, коммитов, роллбаков и подобных ухищрений (как на стороне базы данных, так и на стороне приложений), решающих взаимосвязи объектов и субъектов по времени (например - одно событие не может произойти раньше другого и если это другое поступило в базу данных ранее первого, оно не может быть записано до прихода и записи первого ...).
Вот такая беда
ER-диаграмма не учитывает и вообще не рассматривает процессы. Это как бы не секрет..
Не согласен. Еще как учитывает (даже если вы этого не хотите) - в каждой стрелочке, которая называется relationship.
Само установление отношения между физическими данными (внешний ключ, прямая ссылка) осуществляется движком базы данных, занимает определенное время и потребляет ресурсы, не говоря уж о дальнейшей постоянной поддержке этой связи.
Да и на уровне приложения - отношения между объектами/данными а) устанавливаются б) изменяются в) удаляются.
Чего уж говорить, вы когда еще только рисуете диаграмму, уже по нескольку раз создаете/таскаете/убираете связи, и ведь не просто так же? - вы моделируете что-то.
Заметьте сколько глаголов я употребил, то есть действий, процессов.
o_O походу вы меня просто не поняли.
Из 4 базовых единиц, выявляемых в ходе анализа (сущности, атрибуты, связи, процессы), только первые три находят непосредственное отражение в диаграмме, процессы же либо выводятся за пределы БД (т.н. клиентская логика), либо конвертируются в набор единиц трёх первых типов, обеспечивающих также учёт моментного состояния во времени, т.е. истории либо динамики состояния. Анализ вообще процесс итерационный.
А то, о чём вы говорите, к делу вообще не относится.
Связь в данном случае это то, как две сущности взаимодействуют между собой.
Вот прямо в предисловии статьи связь это взаимодействие(процесс).
Посмотрите также очень красивый рисунок под названием "Инфологическая модель" - все связи до единой обозначены исключительно глаголами, то есть процессами, действиями.
Вы представляете эти диаграммы как начальный кадр в кино (один из 24 или какой FPS у вас оборудование даст), но ведь база данных это не только SQL-скрипты создания первоначального таблиц, индексов и заполнения справочными статичными данными. Наверное же база данных создается для того, чтобы в нее класть информацию.
Как я уже упоминал выше, сам механизм тактирования записи информации является основой работы нынешних вычислительных систем, так что с временнЫми метками записи информации вроде бы проблем нет. Но записанная информация - это прошлое, а базу данных вы проектируете надеюсь для исполнения/вычисления планируемого будущего (список кино или книг можно и в Lotus 1-2-3 сделать).
И да, кстати, а из чего вы сделали вывод, что имеется только 4 базовые единицы (в ваших терминах) анализа процессов для построения данных? Как минимум упустили цель, план достижения цели, контроль достижения, анализ результата. Не атмосферу же вы просто погреть собрались? Зачем тогда все эти диаграммы?
Ваше замечание, что анализ это итерационный процесс, это только подтверждает - для анализа нужны каждый раз свежие данные, чего одни те же цифры каждый раз анализировать. Верно ведь?
А про семантику … Есть такое уникальное слово в русском языке - длинношеее (три е подряд), переведите его допустим на латынь и обратно, смысл будет серьезно искажен. Язык общения, даже технический, сильно зависит от контекста, этики и времени.
Но отсутствие в подобных использованной в данной статье моделях временнОй оси требует создания триггеров, стопов, коммитов, роллбаков и подобных ухищрений
Что-то я не понял проблемы. Есть диаграммы UML, позволяющие описывать сущности во времени. Так же можно использовать stateful database, добавлять временные метки.
В статье речь не о диаграммах UML. И речь не о простом добавлении временных меток.
Как вы разрешите временнУю коллизию, которую я как ну самый простой пример написал выше "(... - одно событие не может произойти позже другого и если это другое поступило в базу данных позже первого, оно не может быть записано до прихода и записи первого ...)" в реляционный базе данных? Именно в базе данных, а не в приложении? Без специальных ухищрений? А если таких коллизий несколько/много?
В статье то ведь речь идет о том, что ER диаграммы позволяют проектировать базу данных как говорится под ключ.
Как я указывал в другом комментарии, ER в изложенном в статье виде дает лишь статический слепок базы данных в определенный момент времени, однако, если связи/отношения расшифровать и соотнести с процессами/взаимодействием (хоть интегрированными уравнениями, хоть FSM моделями, хоть еще чем) на шкале времени, то бОльшую часть временнЫх коллизий можно решить моделью базы данных. Часть коллизий, связанных с изменением прошедших событий, разрешить уже не удастся, по крайней мере я не смог.
При этом, надо отметить - в нереляционных базах данных (особенно графовых) часть таких коллизий могут быть решены стандартными средствами движка базы данных и ее структурой. Колоночные базы данных, с моей точки зрения, совсем не боятся временнЫх коллизий.
Спасибо, с удовольствием прочитал.
Для связей 1:М можно использовать как список (массив) FK в первой таблице, так и обычный FK во второй таблице
список (массив) FK в первой таблиц
Прям как полноценные FK (с ограничениями целостности и каскадным удалением)? Независимо от СУБД? И не повлияет ли размер массива на производительность?
Для связей 1:М можно использовать как список (массив) FK в первой таблице, так и обычный FK во второй таблице
Нет. Два описанные способа реализуют принципиально разные типы отношения. И различаются они - направлением.
В целом статья хорошая для начала. Но жизнь, как всегда, богаче на варианты.
Имя сущности становится именем таблицы.
Не обязательно так. Сущность может храниться и в нескольких таблицах. Особенно, если разные атрибуты имеют разный тип историчности.
Первичный ключ (Primary Key) — уникальный идентификатор кортежа (например, student_id). Не допускает NULL ...
Если ПК состоит из нескольких полей, то некоторые из них могут быть NULL. Встречался даже случай, когда любое из полей ПК могло быть NULL, но не все сразу.
Речь не о констрейнтах ПК в классических СУБД (там, действительно, действует ограничение NOT NULL), а о "логических" ПК, например, в хранилище.
Спасибо за отзыв!
Сущность может храниться и в нескольких таблицах.
Согласен, реализация структуры БД может разниться в зависимости от требований к хранению и взаимодействию с данными. В статье я описал общий алгоритм для преобразования инфологической модели в даталогическую.
Если ПК состоит из нескольких полей, то некоторые из них могут быть NULL.
В теории, при условии, что первичный ключ состоит из нескольких полей И каждая строка содержит уникальный первичный ключ, то такое возможно имеет место быть. Но я не видел чтобы это было частой практикой.
Семантическое моделирование...
С таким заголовком надеялся увидеть упоминания: онтология, триплет, Современные стандарты Семантического моделирования (Linked Data \ Semantic Web) и т.п.
Статья называется "семантическое моделирование". И сплошной сумбур. Ни определения семантическому моделированию, что структуры его компонентов. Откуда взялись уровни даталогический и концептуальный? Какая связь? Просто всё в кучу
Семантическое моделирование. Проектирование БД с помощью ER-модели