Главная страница. Абонентское обслуживание компьютеров в СПб. ИТ аутсорсинг. ИТ аутсорсинг, абонентское обслуживание компьютеров в спб IT-аудит и консалтинг Проектирование и монтаж компьютерных сетей Разработка ПО (программного обеспечения) Продажа лицензионного программного обеспечения Поставка компьютерного оборудования, серверов, комплектующих Контакты. Время работы. Схема проезда
 

Разработка ПО

Стадии разработки ПО

Технологии

Разработка баз данных

ПО собственной разработки

Наши лицензии

Контакты

Наши крупные заказчики по внедрению  IT-проектов

ГУП «Петербургский метрополитен»

Министерство транспорта Российской Федерации ФГУП "ЗащитаИнфоТранс"

Оставить отзыв

Отзывы клиентов

Проектирование и разработка баз данных (БД) на заказ. Часть 1.

Одним из ключевых элементов информационной системы является уровень хранения и обработки данных. Именно поэтому вопрос создания баз данных на заказ в последнее время приобретает все большую актуальность. Предлагаемый к рассмотрению материал отражает этапы и методы практического проектирования и разработки баз данных, учитывая доступность широкому кругу программистов теоретических материалов. Для начала следует указать на типовые ошибки, которые допускают инженеры, изучающие вопрос создания баз данных, а именно: мало кто обращает внимание на основные принципы работы систем управления базами данных (СУБД) и теорию хранения информации. Отсюда и возникают временные задержки при обработке транзакций, нарушение целостности и другие малоприятные ситуации при эксплуатации баз данных (БД). Речь идет об определении реляционности и нормализации. В большинстве случаев работа ведется именно с реляционными базами данных, использование которых было предложено еще в 1970 г. IBM. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Модель реляционной БД, состоит из таблиц, представляющих собой двумерный массив и обладающей следующими свойствами:

  • каждый элемент таблицы — один элемент данных;

  • все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.);

  • каждый столбец имеет уникальное имя;

  • одинаковые строки в таблице отсутствуют;

  • порядок следования строк и столбцов может быть произвольным;

На базе этого понятия и предполагается построение нормализованной базы данных. Существует 5 нормальных форм, описание и определение которых можно найти практически в любой литературе (так же есть еще нормальная форма Бойса-Кодда и доменно-ключевая нормальная форма). Практическое применение этих принципов позволяет построить базу, лишенную изъянов, ведущих к нарушению целостности и сократить объемы хранимой информации, что, не смотря на существующие мощности серверов имеет далеко не последнее значение.

1 этап: разработка (проектирование) структуры базы данных.

Перед выполнением работ по проектированию структуры базы данных необходимо не просто знать наборы данных, которые будут храниться в БД, но и хорошо представлять процессы, которые будут реализованы конечными приложениями. В качестве примера можно привести попытку одновременной записи данных в таблицу и попытку удаления тех же данных, к примеру, с двух других рабочих мест. С учетом того, что принцип работы СУБД построен на алгоритме постановки запросов в очередь, уровень СУБД отработает сложившуюся ситуацию, но пользователь осуществляющей вставку и пославший вторым запрос на удаление будут иметь неудовлетворительный результат: первый не увидит результатов записи, второго удивит удаление записей в количестве 0. И это пример, который просто «изумит» пользователей, а может так получиться, что анализ большого объема данных (например: построение графика из расчетных значений) приведет к загруженности базе данных, что повлечет медленную загрузку потока данных (например: данных, снятых с датчика скорости вращения ротора) и вызовет ошибку записи по причине истечения времени ожидания (TimeOut). Приведенные примеры показываю необходимость полного изучения технических процессов, протекающих в информационной системе. Только после безусловного понимания логики работы самой информационной системы имеет смысл приступать к проектированию базы данных. Приведенные примеры показывают, что при разработке базы данных необходимо учитывать принципы распределения прав пользователей и ведение протоколов выполненных операций.

Распределение прав пользователей.

Этот вопрос имеет два аспекта:

  • информационная безопасность (несанкционированное использование данных);

  • исключение «непонятных» с точки зрения пользователя ситуаций и распределение функциональных возможностей;

Вопрос информационной безопасности имеет смысл решать стандартными средствами СУБД. Они позволяют гибко настраивать права доступа ко всем объектам базы данных. Следует отметить, что в информационных системах строгого функционирования (поясним: системы с жестко определенным алгоритмом работы) целесообразно использовать хранимые процедуры и доступ пользователям разрешать только к их выполнению. При необходимости оперативного построения отчетности или выполнения других «одноразовых» задач можно использовать для составления запросов консоль управления СУБД с правами администратора.


Перед проектированием базы данных следует четко определить: будет ли оправданным заведение в базу данных таблицы пользователей с заданием их функциональных возможностей в информационной системе. Такой подход предполагает более сложную (а иногда и «запутанную») структуру базы данных, усложненные хранимые процедуры, разработку целой подсистемы управления правами пользователями.

Существуют предпосылки для принятия этого решения:

  • набор функциональности, определенный в базе данных, может быть использован клиентским приложением;

  • большое количество пользователей, выполняющих одинаковые функции в системе;

С первым пунктом ясно: программному приложению целесообразно использовать конфигурацию, размещенную централизованно. Относительно второго пункта необходимо точно взвесить все «за» и «против». Давайте представим, что в информационной системе порядка 10 тысяч пользователей выполняющих одни и те же функции. Можно использовать средства распределения прав пользователей СУБД и завести всех пользователей «скриптом» или выполнять эту работу по «необходимости» (если пользователи подключаются к работе постепенно). Или можно всем дать одно и тоже имя входа. Решения есть. Но если Вам понадобиться определить пользователя, удалившего данные – вы не сможете это сделать. А такие задачи в рамках сопровождения крупных информационных систем встают практически ежедневно.
В любом случае, определять степень необходимости усложнения структуры базы данных только Вам.

По всем вопросам проектирования и разработки баз данных на заказ, обращайтесь в наш отдел продаж по
т. (812) 933-69-51; 336-20-51, 336-20-55.

 
Rambler's Top100