Рубрика «проектирование баз данных»
Базы данных. Основа реляционных баз
2026-01-25 в 6:16, admin, рубрики: sql, базы данных, основы реляционных баз данных, первичные ключи, проектирование баз данных, реляционные субд, СУБД
Как ИИ помогает проектировать базы данных
2025-12-16 в 16:35, admin, рубрики: database design, архитектор бд, дизайн баз данных, информационные системы, проектирование баз данных, проектирование бд, сезон ии в разработке, системная аналитика, создание стартап проектов, создать базу данных в таблицахНейросети резко ворвались в нашу жизнь. Для кого-то это возможность смотреть или генерировать прикольные и не очень картинки и видео, которые многим уже надоели. А для нас, коллеги, это мощный инструмент, позволяющий быстрее решать различные задачи.
ИИ понижает порог входа в многие отрасли ИТ – например умея задавать правильные вопросы, при помощи подсказок ИИ вы можете запросто настроить Nginx-сервер на Ubuntu под нужды ваших проектов, привязав домены, выпустив SSL с автопродлением, даже если вы ни разу не пользовались Ubuntu, не шарите в Nginx и т.д.
Анатомия системы НСИ
2020-03-15 в 12:13, admin, рубрики: oracle, oracle 18c, Анализ и проектирование систем, НСИ, проектирование баз данных, Проектирование и рефакторинг, справочные системыДанная статья основана на реальных событиях,
и все проблемы в ней не вымышленные. (С)
В начале хотелось бы отметить, что статья не призвана показать изобретение велосипеда, потому как многие приёмы уже давно существуют в культуре разработки баз данных. Однако обобщить, проанализировать проблемы, которые они могут решить и показать, как с ними можно работать. А проблем хватает несмотря на то, что нормативно-справочная информация (НСИ) не относится к бизнес-логике, а скорее находится в обслуживании у неё. Стандартный процесс по рисованию очередной таблички для хранения справочника очень скоро начинает обрастать костылями или трудоёмкими переделками.
Читать полностью »
Роли, их моделирование в ИС
2017-11-12 в 12:55, admin, рубрики: IT-стандарты, Анализ и проектирование систем, бизнес-анализ, бизнес-модели, моделирование предметной области, проектирование баз данных, роль, СемантикаПусть есть пользователи информационной системы. Авторизованным пользователям позволено строить свои модели в этой ИС. Неавторизованные могут только смотреть, как другие строят эти модели, но сами не могут этого делать.
Вопрос: сколько ролей в ИС?
Пусть есть две кучи песка, сваленные рядом.
Вопрос: Это одна куча, или по-прежнему две кучи, но теперь сваленные рядом?
Пусть есть должность директора школы №123. Сидоров занимает эту должность после Иванова.
Вопрос: это два разных директора, или один директор?
Сегодня Иванов играет роль княжны Мэри.
Вопрос: завтра, когда он будет играть роль с тем же названием, это будет та же роль, или другая?
Вопрос: Сидоров, который сегодня играет роль с тем же названием, играет ту же роль, или другую?
Есть часовой механизм, исполняющий роль часового привода в часах на городской башне. Пусть он сломался и его заменили на другой часовой механизм.
Вопрос: часовой привод теперь другой, или это тот же часовой привод, но с другим часовым механизмом?
Читать полностью »
Подход к разделению схем (пользователей) при проектировании OLTP баз данных
2017-09-15 в 10:20, admin, рубрики: oracle, PL/SQL, Анализ и проектирование систем, Программирование, проектирование баз данных, СУБДПроблематика и назначение:
Разделение схем в основе своей реализуется для масштабируемости и безопасности:
- Масштабируемость с точки зрения баз данных должна быть такой, чтобы схему можно было вынести в другую базу без ущерба функционалу.
- Безопасность с точки зрения баз данных должна быть такой, чтобы внешние пользователи оперировали только бизнес логикой, к которой раздаются гранты, и не имели доступа к первичным данным.
Что нужно учесть при проектировании системы, чтобы не было мучительно больно?
2017-05-19 в 13:55, admin, рубрики: sql server, Анализ и проектирование систем, проектирование баз данных, стартапВ статье описаны проблемы при проектировании баз данных и немного всего приложения, которые потом с ростом проекта все сложнее и сложнее решить. Моменты, которые важно учесть на этапе дизайна, и не задумываться о них в последствии. Ну или задумываться за чашкой чая и фразой «А помнишь, как мы решили это сделать сразу? Сколько времени мы этим себе сэкономили!», а не с ощущением зубной боли и болезненном вздрагивании при каждом воспоминании. По мере роста системы и числа пользователей, дизайн базы все сложнее и сложнее изменить, и масштаб изменений становится все более глобальным и трудоемким.
Сейчас многие успешные проекты выросли из небольших стартапов, которые потом получили коммерческий успех и стали большими международными компаниями. Такая возможность роста появилась в последние 20 лет, в основном благодаря интернету и эффекту «стирания границ». Появились глобальные интернет-приложения и мобильные приложения, которые могут быть использованы в любой стране. Ранее, чаще всего, если приложение должно было быть международным проектом, оно и проектировалось уже сразу с учетом такого требования. Конечно, можно воспользоваться эволюционным подходом, и по мере роста проекта добавлять в него необходимые функции и масшатибирование. Но для облегчения внедрения дальнейших изменений, необходимо сразу учитывать масштаб некоторых базовых функций, изменить которые в дальнейшем сложно.
Я работала в 2х стартап-проектах, которые выстрелили и выросли в большие компании с миллионами пользователей из маленьких региональных проектов, и сейчас являются высоконагруженными. К моему удивлению я увидела, что есть много общих проблем, хотя приложения писались разными командами и для разных пользователей. Видны общие проблемы в базах данных, которые являются наследием стартапа, такими детскими проблемами роста, которые показывают, что изначально проект был запланирован маленьким.
Всё, что вы не знали о CAP теореме
2017-05-16 в 11:28, admin, рубрики: acid, base, cap, cassandra, mongodb, nosql, pacelc, postgresql, Анализ и проектирование систем, архитектура, базы данных, проектирование, проектирование баз данных, распределенные системыВо время моего первого опыта работы с распределенными системами я постоянно сталкивался с некой CAP-теоремой, пришлось изрядно покопать, чтобы изучить и осознать её со всех сторон. Я не являюсь мастером баз данных, но надеюсь, что мое маленькое исследование мира распределённых систем будет полезно для обычных разработчиков. В статье я расскажу о том, что такое CAP, его проблемы и альтернативы, а также рассмотрим некоторые популярные системы баз данных через CAP призму.
Читать полностью »
Пилим каталог товаров не притрагиваясь к реляционной алгебре
2017-03-15 в 12:07, admin, рубрики: orientdb, sql, Анализ и проектирование систем, проектирование баз данных, метки: orientdbЗдравствуйте, меня зовут Дмитрий Карловский и я… давно не занимался бэкендом, но на днях вдруг наткнулся на мучения SbWereWolf по натягиванию ужа на ежа и не смог удержаться от соблазна сдуть пыль со своего мульти-инструмента OrientDB да оттяпать им чего-нибудь этакого.
Итак, мастерить мы сегодня будем базу данных для интернет-магазина с поиском товаров по параметрам, полнотекстовым поиском, локализацией, автоматическим формированием рубрикатора и мастера добавления товара.
Разбирать мы будем вот этот вот реляционный звездолёт:
А собирать вот такой вот графовый скворечник:
Вы не любите триггеры?
2016-09-15 в 11:35, admin, рубрики: oracle, postgresql, sql, triggers, Анализ и проектирование систем, базы данных, нормальные формы, проектирование баз данныхВы не любите кошек? Да вы просто не умеете их готовить! (с) Альф
При проектировании достаточно объёмных реляционных баз данных часто принимается решение об отступлении от нормальной формы — «денормализации».
Причины могут быть разными. От попытки ускорения доступа к определённым данным, ограничений используемой платформы/фреймворка/средств разработки и до недостатка квалификации разработчика/проектировщика БД.
Впрочем, строго говоря, ссылка на ограничения фремфорка и т.п. — по сути попытка оправдать недостаток квалификации.
Денормализованные данные — слабое звено, через которое легко можно привести нашу базу в неконсистентное (нецелостное) состояние.
Что с этим делать?
Читать полностью »
Проектирование модели расширенных типов над базой данных
2016-01-13 в 5:17, admin, рубрики: Блог компании Enterra, проектирование баз данных, хранение данныхО приложении
MobiDB Database Designer – приложение для создания реляционных баз данных. Предназначено как для бизнеса, так и для повседневного использования, поддерживает синхронизацию и много пользователей. Позволяет хранить различные типы данных. Подходит для планирования, управления проектами, формирования счет-фактур, организации доставки, инвентаризации, ведения пациентов в больнице и т.п.
Идея проекта
Идея проекта заключалась в создании дизайнера базы данных с таблицами и соответствующих форм просмотра/ввода на тач-устройствах. При этом хотелось, чтобы было удобно и просто создавать базу данных. В итоге решили дизайнить базу на основе формы. Т.е. накидывалась форма ввода данных, на ее основе создавалась база данных и карточки для ввода этих данных. Удаление/добавление контрола приводило к удалению/добавлению колонки в базе данных.
Выбор технологии
Проект изначально предусматривалось делать для нескольких мобильных платформ (для начала android, позже планировали сделать windows store приложение). Писать нативный код означало писать код для всех платформ с нуля. Использовать кроссплатформенные решения (чтобы UI тоже был общим), не хотелось. Хотелось, чтобы приложение было “родным” на каждой платформе. Имея опыт .NET разработки и изучив возможные кроссплатформенные решения, мы выбрали Xamarin. Можно было написать общий код и разный UI, чего мы и хотели. Данная статья не будет касаться специфики Xamarin, а посвящена архитектурным вопросам.
Разрабатывали проект последовательно, сначала модель данных, затем слой данных, после этого UI часть. Описание UI части не входит в рамки данной статьи.
Базу нужно было где-то хранить, клиент должен был работать offline, поддерживаться всеми основными платформами, поэтому ничего лучшего, чем SQLite не нашлось.
Читать полностью »