Хранение данных


Каким должно быть хранилище информации
Зачем нужно накапливать и хранить информацию? Для чего надо тратить силы и время на создание хранилища и поддержания его в исправном состоянии? Сумев четко ответить на эти вопросы, вы сможете определиться с целями при создании хранилища информации. Итак, у нас есть два основных типа работ: постоянные и разовые. К постоянным относим то, что нужно делать ежедневно, — это, например, наблюдение за рынком и его составляющими. К разовым относим те, которые возникают «вдруг» и по окончании не требуют внимания. Если изучать постоянные, то получается, что время от времени возникает ситуация, когда нужно вернуться немного назад и уточнить некоторые детали. Детали, которые тогда были не важны, а сейчас перешли в разряд первостепенных, детали, которые позволят взглянуть иначе на имеющийся материал, детали, упущенные ранее, и т.д. Эти самые детали можно почерпнуть только в хранилище данных. А поскольку, работая над проблемой, вы не можете предполагать, что вам понадобится впоследствии, важно сохранить информацию в первозданном виде — в том виде, в каком она к вам поступила. Ситуация с разовыми мероприятиями несет в себе еще один важный элемент. Он заключается в том, что, закончив работу по одному проекту, вы не можете и предполагать, с чем эта информация может скоррелировать в будущем,
где еще могут пригодиться собранные вами сведения. Именно неопределенность будущего и заставляет скрупулезно накапливать собранную информацию. Исходя из этого и нужно подходить к разработке и созданию базы данных.
Каким требованиям должна отвечать создаваемая база? Попробуем их сформулировать. К пользовательским требованиям можно отнести: легкий и быстрый доступ к искомому материалу; возможность хранения в базе огромных объемов информации; возможность хранения в одной записи значительного объема информации с возможностью полноценного поиска.
В качестве общих требований нужно упомянуть: простота управления базой, в т.ч. копирования и архивирования данных; надежность хранилища; максимально возможное сжатие материала.
Требования по своей сути простые и понятные. Но в сочетании с особенностями планируемого к хранению материала они становятся достаточно жесткими. Возьмем, к примеру, «возможность хранения в одной записи значительного объема информации с возможностью полноценного поиска». В общем- то нормальное требование, но вспомним, что мы собираемся хранить в этой базе. Это в основном текст. А его размеры могут колебаться от нескольких предложений до нескольких томов. Соответственно и размеры одной записи будут колебаться от нескольких килобайт до десятков (а иногда и сотен) мегабайт. При таком разбросе нельзя, чтобы база резервировала огромный объем всякий раз при создании пустой записи. В противном случае такая база очень быстро станет занимать огромное дисковое пространство. Поэтому размер записи должен быть переменный и зависеть от объема внесенной в эту запись информации.
Простая файловая система
Самый простой способ хранения текстовых данных на ПК — это обычная файловая система. Один файл — один информаци
онный блок. При этом нельзя все файлы сваливать в одну директорию, дав им названия «Инфо-1», «Инфо-2», «Инфо-3» и т.д. При таком подходе очень скоро вы не сможете ориентироваться в своем хранилище. А само хранилище превратится скорее в кладбище информации.
Для недопущения такой ситуации необходимо придерживаться нескольких простых правил: во-первых, присваивайте файлам осмысленные имена - название объекта интереса, благо современные системы поддерживают длинные имена файлов. Структура же самого имени должна быть следующей: первая часть имени — название объекта интереса, а вторая — характеристика содержания файла. Например, «РАО ЕЭС СМИ 2005» или «Бендукидзе Состав ФПГ». во-вторых, каждому проекту должна соответствовать своя директория (папка) с названием, соответствующим объекту интереса. При большом количестве материала, в каждой такой папке-проекте можно создать подпапки: «СМИ», «Новости», «Отчетность», «Аналитика»; если объект попадает в несколько проектов, то основной файл должен храниться в папке одного проекта, а во всех остальных местах присутствия создается ярлык этого файла.
При соблюдении этих правил вы сможете ориентироваться в своем хранилище и пусть не мгновенно, но все же достаточно быстро находить нужную информацию. Такой способ хранения подходит для незначительных объемов данных и вполне приемлем на начальном этапе работ, но в дальнейшем вам все равно придется перейти на иной способ организации хранилища.
Можно несколько развить данный способ хранения информации. Например, создав виртуальные папки под каждый проект и поместив в них ярлыки соответствующих файлов или папок. То есть для каждого нового объекта создается своя папка с соответствующим названием, а объединение объектов в проект происходит посредством виртуальных папок и ярлыков.
А в операционной системе VI 51а предусмотрены свои (внутрисистемные) виртуальные папки. Правда, их заполнение происходит в основном по ключевым словам, но тем не
менее это достаточно удобно. Особенно если взять за правило в каждом документе указывать ключевые слова, в том числе и неявные.
Файловая система с программной надстройкой
Рано или поздно, несмотря на все усилия, файловый способ хранения данных не сможет обеспечить оперативность и точность ориентирования в массиве данных. Функции поиска необходимо передавать от человека компьютеру. Можно развивать уже сложившуюся файловую систему хранения данных, дополнив ее некой программной надстройкой. Такая программная надстройка должна выполнять следующие функции: присвоение неких (заранее вами определенных) хранимым атрибутов файлам; виртуальная группировка файлов по принятым блокам (проектам, папкам, группам и т.п.); визуальное представление этой виртуальной файловой системы; поиск по атрибутам файлов; поиск по содержимому файлов, в т.ч. с поддержкой логических операторов.
Такая надстройка значительно облегчит работу с информацией. Во-первых упростится поиск нужной информации — не нужно будет вспоминать, где оно может быть, а просто ввести искомый термин. Во-вторых, не нужно будет отвлекаться на создание и поддержание файловой структуры — это сделает сама программа. Но и такой способ хранения информации имеет свои ограничения, хотя и наиболее удачные программные решения в данной области позволяют перерабатывать огромные объемы информации.
База данных
А можно пойти по пути создания полноценной базы данных (БД). Этот путь сложнее, но и эффективность такого хранилища будет выше. Например, цифровую информацию можно будет легко обрабатывать средствами СУБД. Можно использовать
статистические функции СУБД. Для такой БД нужно значительно меньше дискового пространства в силу специфического формата хранения данных и исключения дублирования данных, а значит, и поиск будет вестись быстрее, особенно при оперировании миллионами объектов. В настоящее время это наиболее прогрессивный метод хранения данных. Вопрос в том, какова должна быть структура такой базы данных. Именно от структуры будет зависеть ее эффективность. Наиболее простая и функциональная структура БД состоит из следующих таблиц: «Информация», «Организация», «Лицо», «Адрес»,
—«Телефон», «Проект».
В таблицу «Информация» попадают все информационные блоки, которые признаны вами интересными или полезными. Здесь будет храниться вся исходная информация. По-хорошему, сюда же должны попадать сведения о событиях значимых и не очень, о ваших работах и результаты этих работ (отчеты, справки, письма и т.п.). В дальнейшем этот блок имеет все шансы перерасти в вашу базу опыта. Не забывайте присваивать каждой информации все необходимые атрибуты. Фактически нужно создать поля с этими самыми атрибутами. Какие атрибуты вы задействуете, будет зависеть от поставленных задач. Наиболее востребованными являются следующие атрибуты: дата ввода информации; дата публикации; автор; источник; канал поступления; название.
И никогда не меняйте однажды введенную информацию - лучше уж ввести дополнительную с необходимыми изменениями и соответствующим комментарием.
В таблице «Организация» будут храниться структурированные данные об организациях. Под эту категорию подпадают юридические лица, неформальные объединения (в т.ч. и ОПГ) —
в общем, все, что относится к организациям в широком смысле этого слова. А структура данной таблицы полностью зависит от решаемых вами задач.
В таблице «Лицо» должна храниться структурированная информация о людях. Структура также зависит от ваших задач.
Таблица «Проект» необходима для того, чтобы вы не потерялись в вашей информации, когда число записей будет исчисляться тысячами и более, и всегда могли понять, в связи с чем изучался тот или иной объект.
Отдельного пояснения требуют таблицы «Адрес» и «Телефон». Поскольку и та и другая сущность может принадлежать нескольким объектам, для исключения дублирования информации и, как следствия, путаницы необходимо исключить двойной ввод данных. А принципиально исключить такую ситуацию можно ведением персонального реестра или, иначе говоря, выделением этих сущностей в отдельные таблицы.
Дополнительно нужно сказать о связях внутри базы данных. Они создаются программными средствами в зависимости от особенностей используемой СУБД. Есть два принципиальных способа создания связей в БД: создание между двумя таблицами одной-единственной связи с комментарием и внесение этого комментария в зависимости от ситуации; создание между двумя таблицами всех возможных вариантов связей и активирование необходимых в зависимости от ситуации.
У каждого подхода есть свои плюсы и минусы, поэтому отдавать предпочтение какому-то из них необходимо исходя из конкретных условий.
<< | >>
Источник: И.Ю. Нежданов. Аналитическая разведка для бизнеса. 2008

Еще по теме Хранение данных:

  1. 11.4. Хранение данных
  2. § 3. ОСОБЕННОСТИ ДОГОВОРА ХРАНЕНИЯ С ОБЕЗЛИЧИВАНИЕМ ВЕЩЕЙ. БЕЗДОГОВОРНОЕ ХРАНЕНИЕ
  3. Глава 3 Защита персональных данных и обеспечение конфиденциальности данных в Шенгенской информационной системе
  4. 3. Особенности временного хранения товаров на складах временного хранения таможенных органов
  5. 4. ПРОЦЕДУРА ВРЕМЕННОГО ХРАНЕНИЯ. СКЛАД ВРЕМЕННОГО ХРАНЕНИЯ
  6. § 4. Исследование фактических данных о              заподозренном, связанных с субъективной стороной преступления Источники данных о субъективной стороне убийства.
  7. Права на программы для ЭВМ и базы данных. История развития законодательства о правовой охране программ для ЭВМ и баз данных
  8. Определение методов сбора маркетинговых данных 4.5.1. Общая характеристика методов сбора данных
  9. 16.5. Договор хранения
  10. 26.1. Понятие договора хранения
  11. 3.4. Временное хранение товаров