Основные циклы базы данных

Базы данных (БД) являются основным компонентом автоматизированной информационной системы (АИС), поэтому их жизненный цикл неразрывно связан с жизненным циклом АИС и жизненным циклом ее программного обеспечения.

Определение 1

Жизненный цикл АИС – период времени, начало которого определяется моментом принятия решений о необходимости создания АИС и заканчивается завершением её полной эксплуатации.

Существует $2$ наиболее распространенные модели жизненного цикла: каскадная и спиральная. Жизненный цикл БД чаще всего соответствует спиральной модели.

Этапы жизненного цикла БД

Жизненный цикл БД проходит несколько этапов:

Планирование разработки БД
Определение требований к системе
Сбор и анализ требований пользователей
Этап проектирования (моделирования) БД
Выбор целевой СУБД
Разработка приложений
Создание БД
Конвертирование и загрузка данных из старой системы
Тестирование БД
Эксплуатация и сопровождение

Планирование разработки БД

Этап подготовительной работы, который позволяет максимально эффективно реализовать этапы жизненного цикла БД.

На данном этапе:

анализируется функционирование автоматизируемого предприятия соответственно требованиям, которые ему представляются: определяются бизнес-планы и цели предприятия, после чего выделяется необходимость использования предприятием информационных технологий;
анализируются существующие на предприятии автоматизированные информационные системы для выявления их сильных и слабых сторон (однопользовательские системы, устаревшее программное обеспечение и т.п.);
формулируется необходимость использования новой АИС (определяются все недостатки подобных АИС, их стоимость, сложность сопровождения и т.п.);
разрабатываются стандарты, которые определяют технологию сбора данных, формата данных, определяется состав необходимой технической документации, схема проектирования и реализации.

Определение требований к системе

На данном этапе:

анализируется и выбирается направление улучшения объекта управления в рамках данного предприятия;
устанавливаются границы исследуемой области;
определяется связь разрабатываемой системы с существующими на предприятии АИС;
выбираются программно-технические средства;
определяется ограничение ресурсов на разработку;
определяется состав возможных будущих клиентов;
определяются направления развития.

Сбор и анализ требований пользователей

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

На данном этапе формируется и утверждается минимум документов для проектирования программной системы, среди которых название задания, организационная структура предприятия, структура входящей и исходящей документации, функции автоматизации, описание предметной области, требования к программному и техническому обеспечению АИС и т.п.

Этап проектирования (моделирования) БД

Создается проект БД, отображается словесное и естественное описание предметной области в схеме внутренней модели БД.

БД проектируется с целью:

представления данных и связей между ними, которые необходимы для всех областей применения БД и групп пользователей;
создания модели данных, которая способна поддерживать выполнение требуемой обработки данных;
разработки предварительного варианта проекта со структурой, которая способна удовлетворить все основные предъявляемые требования к производительности системы.

Выбор целевой СУБД

Выбор СУБД осуществляться на любом этапе разработки БД при условии наличия всей необходимой информации о производительности системы, стратегии реализации ограничений целостности БД, уровне защищенности данных, архитектуре вычислительной среды, необходимости параллельной обработки данных.

Разработка приложений

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

Создание БД

Физическая реализация БД в среде СУБД состоит из:

создания схемы БД;
реализации прикладных программ с использованием языка программирования (во многих СУБД язык программирования встроен);
реализации элементов прикладных программ;
разработки экранных форм для ввода и вывода данных;
реализации мероприятий по защите информации.

Конвертирование и загрузка данных из старой системы

Перенос существующих данных из старой системы в разработанную БД и изменение существующих приложений для организации совместной работы с новой БД в случае, когда разработанная БД заменяет или содержит информацию старой БД.

Тестирование БД

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

Эксплуатация и сопровождение

Работа системы сопровождается наблюдением и поддержкой нормального функционирования:

контролируется производительности системы и при необходимости проводится дополнительная настройка или реорганизация БД, оптимизация запросов, создаются дополнительные объекты;
сопровождаются и модернизируются, при надобности, элементы прикладных программ;
проверяется эффективность системы блокировок в параллельных процессах, осуществляется мониторинг работы системы, создаются резервные копии БД и т.п. – администрирование БД.

Источник

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 28 октября 2015; проверки требуют 9 правок.

Циклическая база данных (англ. Round-robin Database, RRD) — база данных, объём хранимых данных которой не меняется со временем,[1] поскольку количество записей постоянно, в процессе сохранения данных они используются циклически[2][3][4]. Как правило, используется для хранения информации, которая перезаписывается через равные интервалы времени.

Наибольшее применение нашла в программе MRTG, которая позднее была вытеснена пакетом программ RRDtool[5].

СУБД и интерфейсы для циклической БД включены в репозитории крупнейших дистрибутивов Linux[6][7][8][9] и в хранилище Perl библиотек CPAN[10]. Также СУБД RRDtool доступна как модуль для CMS Drupal[11].

Структура БД[править | править код]

Внутренняя структура циклической БД:

RRA (англ. round-robin archive) — циклический архив DS (англ. data source) — таблица для соответствующего источника данных

Одна циклическая база данных можеть хранить один или несколько наборов данных, которые объединяются в архивы (RRA — round robin archive). Кольцевые таблицы архивов по структуре аналогичны массивам, у которых адрес последнего элемента совпадает с адресом первого элемента. Положение последнего обновленного элемента хранится в виде указателя. Архивы, как правило, связаны между собой как матрешки, каждый последующий архив хранит консолидированную информацию из предыдущего. Для этого используются функции консолидации, встроенные в базу данных. Это позволяет применять эти функции автоматически при обновлении информации в БД. Один архив хранит данные с небольшим интервалом между записями, другой, через заданное количество интервалов, сохраняет консолидированные данные из предыдущего, последующий делает это ещё реже и т. д.[12]

Консолидация данных[править | править код]

Если записывать данные через небольшие интервалы времени, а потом формировать среднее (максимальное, минимальное и т. д.) значения за год или любой другой достаточно большой интервал времени, то вычисления и сам процесс выборки из БД может потребовать большое количество ресурсов. Для того, чтобы избежать этого, в циклических базах данных используется консолидация данных при записи, а не во время считывания. Периодов консолидации может быть сколько угодно (неделя, месяц, квартал, год и т. д.). Для осуществления вычислений используются специальные функции консолидации (англ. consolidation function, CF), такие как:

average — среднее значение
minimum — минимальное значение
maximum — максимальное значение
total — общее значение

Типы данных[править | править код]

Основные типы данных:[13]

COUNTER
GAUGE
DERIVE
ABSOLUTE
COMPUTE

COUNTER — это счетчик, значение которого может только увеличиваться, при сохранении данных такого типа из текущего значения вычитается предыдущее.

GAUGE — произвольные значения. Данный тип используется для данных, которые могут как уменьшаться, так и возрастать (допустим температура объекта).

Тип DERIVE — это тот же счетчик, но с возможностью хранить не только постоянно возрастающие, но и убывающие значения, то есть разница между смежными значениями может быть отрицательной. При этом важно помнить, что для этого типа не производится проверка на переполнение.

ABSOLUTE — это тоже модификация счетчика, отличие состоит в том, что разница между значениями не вычисляется, а сохраняются сами значения счетчика и счетчик обнуляется при чтении. Этот тип удобно использовать для подсчета количества событий, произошедших с момента последнего считывания.

Тип COMPUTE используется для записи вычисляемых значений на основании данных из других источников данных (англ. Data Source, DS) текущей БД RRD. В теории баз данных такие поля называют вычисляемыми или виртуальными. Этот источник данных не указывается при операции обновления (update), но его основные контрольные значения (англ. Primary Data Points, PDPs) вычисляются из основных контрольных значений (PDPs) других источников данных, путём применения к ним формул записанных в формате обратной польской записи (англ. Reverse Polish Notation, RPN). Функции консолидации тоже применимы к этому типу данных.

Интерполяция данных[править | править код]

В связи с тем, что циклические базы данных часто используются для представления данных, распределенных во времени через равные интервалы времени, в механизме такой базы предусмотрена следующая особенность: если при записи в базу по каким-то причинам (например, задержка вычисления значения) данные не были записаны вовремя (например запись произошла на 3 секунды позже), то данные все равно будут записаны так, как если бы они были предоставлены вовремя. Сам «механизм» циклической базы данных изменит данные для коррекции (пропорционально времени запаздывания или отставания). Другими словами, в саму базу данных встроена система корректирования аберраций (англ. Aberrant Behavior Detection). Эта система состоит из трех компонентов:[14]

Механизм математического (статистического) прогнозирования значения следующей порции данных (которые будут записаны).
Механизм вычисления отклонения реальных данных от прогнозированной (расчетной) величины.
Механизм принятия решений в зависимости от степени отклонения значения (или серии значений) от прогнозированной (расчетной) величины.

Как работает интерполяция аберрированных данных легко понять, рассмотрев конкретные значения:

данные в БД RRD	реальные данные
time+000: 0 delta=”U” time+300: 300 delta=300 time+600: 600 delta=300 time+900: 900 delta=300	time+000: 0 delta=”U” time+300: 300 delta=300 time+603: 603 delta=303 time+900: 900 delta=297

Но в БД хранятся не только интерполированные данные, но и данные, которые непосредственно вводились. Это необходимо для более точной интерполяции последующих данных.

Интерполяция данных может привести к их искажению, поэтому сфера применения ограничена областями, где точность не критична. В других областях используют тип данных, к которому механизм интерполяции не применяется.

Примечания[править | править код]

См. также[править | править код]

Мониторинг компьютерной сети
Round-robin (алгоритм)

Ссылки[править | править код]

Универсальный наблюдатель, статья в xakep.ru
[1] (фр.)

Источник

pashalost
Member

Откуда:
Сообщений: 14

При проектирование БД столкнулся с множеством противоречивых мнений о том, могут ли (или является ли плохим признаком) существовать в БД циклические связи (идентифицирующие, не идентифицирующие). Хотелось бы услышать много мнений и аргументов в поддержку того или иного довода.
Вот простой пример т.н. циклической связи:
Таблица игры, в ней содержится информация о всех играх (содержит только PK GameID).
Таблица игроки – в ней содержится информация о всех игроках учавствующих в ОДНОЙ игре (содержит FK GameID).
Таблица раунды – в ней содержатся ВСЕ раунды ОДНОЙ игры (содержит FK GameID)
Таблица Ставки – в ней хранятся все ставки, сделанные любым из игроков в любом раунде любой игры. (содержит FK PLayerID, FK RoundID).
Является ли такая архитектура правильной и/или желательной/нежелательной ?

К сообщению приложен файл. Размер – 11Kb

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

> При проектирование БД столкнулся с множеством противоречивых мнений о том, могут
> ли (или является ли плохим признаком) существовать в БД циклические связи

Могут, не является плохим признаком.

> (идентифицирующие,

НЕ МОГУТ по определению.

не идентифицирующие).

Могут.

Хотелось бы услышать много мнений и
> аргументов в поддержку того или иного довода.

Тут не может особенно быть никаких аргументов. Надо тебе по предметной
области циклические связи — делай. И есть случаи, когда их просто нельзя
сделать (2 и более идентифицирующие связи не могут быть циклическими,
одна из связей цикла должна быть неидентифицирующей и допускать NULL,
иначе ты данные просто не вставишь).

> Вот простой пример т.н. циклической связи:
> Таблица игры, в ней содержится информация о всех играх (содержит только PK GameID).
> Таблица игроки – в ней содержится информация о всех игроках учавствующих в ОДНОЙ
> игре (содержит FK GameID).
> Таблица раунды – в ней содержатся ВСЕ раунды ОДНОЙ игры (содержит FK GameID)
> Таблица Ставки – в ней хранятся все ставки, сделанные любым из игроков в любом
> раунде любой игры. (содержит FK PLayerID, FK RoundID).

А где ты тут нашёл циклические ссылки ? Их тут нет, или я что-то не так понял.
У тебя направление ссылки К Bets (ставки). Вот если бы одна из связей на Bets
была бы направлена в другую сторону, был бы цикл.

Posted via ActualForum NNTP Server 1.5

pashalost
Member

Откуда:
Сообщений: 14

Я сталкивался и с такими мнениями (преподавателей), что не важно, в какую сторону идут связи, если они образуют “круг”, то это уже плохо. Моё, конечно, мнение, что в данном примере всё красиво, нет необходимости что-либо переделывать или пытаться сделать лучше

Бредятина

Guest

pashalost,
В теории БД нет понятия “циклические связи”, “идентифицирующие связи”, “не идентифицирующие связи”. Если же это понятия “реляционной теории”, то напомню, что связи в реляционной модели принципиально не поддерживаются. Сообщите это своим преподавателям. Чтобы они не морочили голову, по крайней мере, следующим поколениям:)
А у Вас откуда такая жестокость – уничтожать игроков, чтобы они не имели возможности поучаствовать еще в одной игре?:) Или Игрок – это не Человек?
Типы сущностей нужно именовать в единственном числе.
И почему Вы используете иностранный язык – тоже преподаватели научили?:)

guest_20040621

Guest

> столкнулся с множеством противоречивых мнений

Не читайте то, что пишут на заборах. Любые циклические связи – это ошибки проектирования.

> Вот простой пример

Это хороший пример плохой структуры. Либо задача поставлена криво, либо – судя по вопросу, это вероятнее – безобразна реализация.

Naf
Member

Откуда: Москва
Сообщений: 2695

тут нет циклов

pashalost
Member

Откуда:
Сообщений: 14

Бредятина, (ржу немогу с ника) с чего вы взяли, что я уничтожаю игроков после игры ? Данный пример маленький кусочек, вырванный из моего проекта. Мне ПОЗАРЕЗ необходимо запомнить СОСТАВ игроков в каждой игре. К сведению, состав игроков от игры к игре может изменяться, поэтому его и храним

pashalost
Member

Откуда:
Сообщений: 14

guest_20040621, обоснуйте ваше суждение, почему не должно с структуре БД существовать “циклических связей” и дайте точную формулировку т.н. циклической связи. Поясню задачу, которую должна выполнять БД. Необходимо собирать статистику всех ставок сделанных игроками во время игры. Важно знать, кто, в каком раунде, и в какой игре сделал ставку (размер ставки тоже необходимо знать). В одной игре учавствует несколько игроков (2-10). Игра состоит из нескольких раундов (1-5). Состав игроков от игры к игре может изменится. Попробуйте(если вас не затруднит) прежложить свой вариант решения поставленной задачи

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

> Я сталкивался и с такими мнениями (преподавателей), что не важно, в какую
> сторону идут связи, если они образуют “круг”, то это уже плохо.

ТЫ НЕ ТАК ПОНЯЛ.

В БД все связи направленные, соотв. цикл надо искать как в орграфе.

Posted via ActualForum NNTP Server 1.5

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

> В теории БД нет понятия “циклические связи”, “идентифицирующие связи”, “не
> идентифицирующие связи”. Если же это понятия “реляционной теории”, то напомню,
> что связи в реляционной модели принципиально не поддерживаются. Сообщите это
> своим преподавателям. Чтобы они не морочили голову, по крайней мере, следующим
> поколениям:)

Ну, это заявления подстать нику, это мы пропускаем…

Posted via ActualForum NNTP Server 1.5

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

On 05/31/2012 05:43 PM, guest_20040621 wrote:

> Не читайте то, что пишут на заборах. Любые циклические связи – это ошибки
> проектирования.

Интересно, почему пользователь “Бредятина” не зналогинился ?

Posted via ActualForum NNTP Server 1.5

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

On 05/31/2012 06:33 PM, pashalost wrote:
> guest_20040621, обоснуйте ваше суждение, почему не должно с структуре БД
> существовать “циклических связей” и дайте точную формулировку т.н. циклической
> связи.

Да не обращай ты внимание на гестов. Это ж гест, ему соврать — не дорого взять.

Поясню задачу, которую должна выполнять БД. Необходимо собирать

Ещё раз, проясни для себя — У ТЕБЯ НЕТ ЦИКЛОВ в твоей текущей БД.
Тебе не о чем беспокоиться.

Posted via ActualForum NNTP Server 1.5

miksoft
Member

Откуда:
Сообщений: 38613

MasterZiv
В БД все связи направленные, соотв. цикл надо искать как в орграфе.

Хм, связи 1:1 вроде как ненаправленные. Хотя используются довольно редко.

По сабжу – один из способов хранение иерархий id+parent_id уже сам по себе содержит цикл. Что ж теперь, из-за какого-то препода отказываться от такого способа?

pashalost
Member

Откуда:
Сообщений: 14

guest = troll ? 🙂
Всё больше склоняюсь к мнению, что не все люди (даже из числа тех, кто знает, что такое SELECT * FROM A JOIN B WHERE …) до конца понимают, что такое циклическая связь.

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

> В БД все связи направленные, соотв. цикл надо искать как в орграфе.
>
> Хм, связи 1:1 вроде как ненаправленные. Хотя используются довольно редко.

Связь — это FOREIGN KEY, как он может быть ненаправленный ?
Не, ну конечно при 1:1 ты можешь сделать два встречных FK, только
записи как вставлять потом ?

> По сабжу – один из способов хранение иерархий id+parent_id уже сам по себе
> содержит цикл. Что ж теперь, из-за какого-то препода отказываться от такого способа?

Там цикл разорваный (т.е. допустимый). Разорваный тем, что связь необязательная,
parent_id всегда NULL-able.

Posted via ActualForum NNTP Server 1.5

guest_20040621

Guest

> почему не должно с структуре БД существовать “циклических связей”

Потому, что это свидетельствует о явной ошибке. Почему это ошибка – читайте Дейта.

> Поясню задачу

Вы не поясняете задачу, вы рассказываете о вашей интерпретации задачи. Любые игры имеют правила. Любая реализация базы данных для регистрации состояний участников игры и ее результатов – реляционное описание этих правил.

Описанный вами вариант прост:

игроки,
игра,
состав участников игры (игра, игроки),
раунд (игра, шаг, игрок, ставка) или
раунд (игра, шаг), ставка (игрок, раунд, шаг ставки, номинал ставки), если в одном раунде игрок может делать несколько ставок.

miksoft
Member

Откуда:
Сообщений: 38613

MasterZiv
Не, ну конечно при 1:1 ты можешь сделать два встречных FK, только записи как вставлять потом ?

1) в некоторых СУБД FK могут быть отложенными и проверяются в момент commit-а.
2) в некоторых СУБД FK нет вообще, но это не мешает установить логическую связь между таблицами.

MasterZiv
Там цикл разорваный (т.е. допустимый). Разорваный тем, что связь необязательная, parent_id всегда NULL-able.

Хм, пытаюсь представить себе “неразорванный” цикл. Что-то ничего не приходит в голову, кроме совсем уж абсурдных вариантов…

Бредятина

Guest

pashalost

Я так и понял:) что Игрок – это участие человека в игре…

Бредятина

Guest

MasterZiv

Ну, это заявления подстать нику, это мы пропускаем…

Не обманывайте себя:) Это импульс к размышлению, только дурак может пропустить:)

Бредятина

Guest

MasterZiv

On 05/31/2012 05:43 PM, guest_20040621 wrote:

> Не читайте то, что пишут на заборах. Любые циклические связи – это ошибки
> проектирования.

Интересно, почему пользователь “Бредятина” не зналогинился ?

Я, Чернышев Андрей Ленидович, не раз логинился. Сразу же блокируют. Здесь же БД нельзя обсуждать:)

Бредятина

Guest

pashalost
guest = troll ? 🙂 Всё больше склоняюсь к мнению, что не все люди (даже из числа тех, кто знает, что такое SELECT * FROM A JOIN B WHERE …) до конца понимают, что такое циклическая связь.

Я Вам открою секрет – никто не понимает:)

Бредятина

Guest

MasterZiv

Там цикл разорваный (т.е. допустимый). Разорваный тем, что связь необязательная,
parent_id всегда NULL-able.

FK – это ограничение целостности, а не связь. В “реляционных системах” связи принципиально не поддерживаются.

pashalost
Member

Откуда:
Сообщений: 14

> В “реляционных системах” связи принципиально не поддерживаются
Вот это действительно высший бред. Можно сказать “апофеоз бреда”. Relation – в переводе с английского означает СВЯЗЬ. Они именно потому так и называются, что основаны на СВЯЗЯХ.

guest_20040621

Guest

> Вот это действительно высший бред.

Вы заблуждаетесь. В данном случае Бредятина абсолютно прав.

MasterZiv
Member

Откуда: Питер
Сообщений: 34637

On 05/31/2012 08:15 PM, guest_20040621 wrote:

> Потому, что это свидетельствует о явной ошибке. Почему это ошибка – читайте Дейта.

Ни о чём это не свидетельствует.
Топикстартер, не поддавайся на провокации всяких гестов !
Я тебе всё достаточно понятно уже объяснил.

Posted via ActualForum NNTP Server 1.5

Ссылка на сообщение

Ссылка (включая название темы)

Ссылка (URL)

Источник