Очень большая самодельная записная книжка
Очень большая самодельная записная книжка
Подскажите пожалуйста, наиболее дешевый способ хранения огромных массивов информации. Скорость передачи данных и время доступа не имеет значения.
Из письма Александра, читателя КГ.
Что же, отчего не порадеть хорошему человеку. Тем более, что вопрос, в общем-то, интересный. Правда, сформулирован очень уж странно. Как только речь заходит об огромных массивах информации такие моменты, как время и удобство доступа, а также скорость передачи информации, приобретают весьма даже важную роль. Кроме того, само понятие дешевизны приобретает конкретный смысл лишь после учета всех параметров. Теоретически возможно построить на базе Microsoft Access систему электронных торгов, например, ценными бумагами, в реальном времени. Однако, чтобы результат стал работать согласно с возлагаемыми на него ожиданиями, понадобится весьма и весьма производительное оборудование. С другой стороны, хранилище данных, опять же теоретически, возможно построить на базе нескольких допотопных PC/XT, однако скорость работы окажется недопустимо низкой. В обоих случаях в разработках не будет никакого смысла, что полностью лишит их практической пользы, а следовательно и какой-либо цены.
В общем, короткого практического совета, чего-нибудь в стиле - пишите на дискеты, увы, не получится. Слишком мало исходной информации. Зато появляется прекрасный повод рассмотреть вопрос хранения данных вообще, и как явление, и как процесс.
По большому счету вопрос оперирования большим массивом данных существует лишь в двух аспектах: либо есть некий большой массив, который необходимо хранить без изменения достаточно длительный промежуток времени, либо есть некий продолжительный процесс, функционирование которого непосредственным образом связано с приемом, обработкой и выдачей информации.
Примером первого варианта может служить обыкновенная электронная библиотека. Конечно, рекламный трюк, демонстрирующий на одной чаше весов высокую кипу бумаги, а на второй - маленький серебристый компакт-диск, производит впечатление. Однако даже такая библиотека, как "пушкинка", туда не уместится. Что уж тут говорить об объеме библиотеке имени Ленина или библиотеке Конгресса. Будучи перенесенными на компакт-диски, они займут достаточно мало места и вполне уместятся в обычной тумбочке под письменным столом. Таким образом, при условии, что пользоваться ею будет всего один человек, все, что необходимо, это надежный носитель и корректно составленная таблица, например, в Microsoft Excel, с полным библиотечным перечнем. Возможно, пример и не совсем корректен, однако он более чем наглядно демонстрирует специфику момента.
Примером второго является работа любой торговой фирмы. Спецификация и цена закупки, номенклатура поступления на склад, накладные на отгрузку, гарантийные ведомости, счета и прочая бухгалтерская информация - все это неразрывно связано с жизнедеятельностью предприятия. Причем важную роль играет буквально каждый этап, от ввода и обработки данных, до вывода статистики и аналитических сводок. Тут уже одним приводом CD-ROM не обойтись.
В общем, если "огромный массив информации" - это просто объемный отсканированный с высоким разрешением фотоальбом, то решением задачи является выбор соответствующего носителя данных из имеющихся на рынке устройств данного класса, а их не так уж и много.
Флоппи дисковод LS-120 формата 3.5 дюйма на 120 Mб (www.parad.ru/txt/DAS/ADrive.htm) придуман не так уж и давно, чуть более полутора лет назад. Однако за прошедшее время устройство значительно усовершенствовалось в техническом плане и резко подешевело в ценовом отношении. Еще летом этого года я видел его в Минске по цене чуть менее ста долларов. Сегодня подобные игрушки производят многие компании, самая известная из которых - SONY. Система LS-120 интересна тем, что чрезвычайно похожа на обычный трехдюймовый дисковод как по методике пользования, так и по принципу применения. Накопитель LS-120 монтируется в обычный отсек для внешних устройств половинной высоты и подключается к шине IDE.
А вот дальше начинаются нюансы. Дело в том, что LS-120 оперирует двумя типами носителей: обычной трехдюймовой дискетой емкостью 1,44 Мб и собственным специализированным картриджем емкостью 120 Мб. Что это дает - не мне вам объяснять.
Формативная емкость
Вторым неплохим аппаратным вариантом решения задачи хранения больших объемов данных может оказаться накопитель с несколько несерьезным наименованием JAZ (www.parad.ru/txt/DAS/ Jaz.htm), предлагаемый фирмой Iomega. Несколько отличаясь по технологии чтения/записи от LS-120, накопитель JAZ позволяет оперировать значительно большими объемами, до 1 Гб. Без использования алгоритма сжатия данных "один гиг" перекачивается примерно за пять минут. За счет компрессии емкость увеличивается в два раза, но и время доступа увеличивается.
Если массив в перспективе предполагается носить (например, в дипломате с работы домой и обратно), то имеет смысл обратить более пристальное внимание на накопители Zip (www.parad.ru/txt/ DAS/Zip.htm) от все той же Iomega. При емкости картриджа от ста до двухсот мегабайт, устройство (во внешнем исполнении) отличается компактностью и низким весом (450 грамм). Кроме того, накопитель Zip, в отличие от всех остальных, позволяет использовать его в качестве основного носителя данных при работе с программным обеспечением наравне с привыч-ным уже жестким диском.
Накопители lomega ZIP выпускаются во внутреннем (интерфейс SCSI и ATAPI) и внешнем (интерфейс SCSI) исполнении. Внутренний ZIP легко устанавливается в любой 3.5" или 5.25" разъём вашего компьютера. Внутренний Zip SCSI подключается к поставляемому в комплекте Zip Zoom SCSI акселератору, который максимально ускоряет работу накопителя. Zip-ATAPI подключается аналогично CD-ROM, IDE НЖМД и т.д. Zip-параллельный порт подключается непосредственно к разъёму параллельного порта. При этом он обладает "прозрачностью" для принтера, что позволяет использовать и принтер, и Zip, не переключая постоянно кабели.
Все, что выходит за рамки столь простых технических решений и призвано не только хранить, но активно обрабатывать большие массивы информации, попадает в другую категорию, именуемую "хранилища данных" (www.ci.ru/inform7_97/astr1.htm). Предположим, для примера, что некоторый творческий коллектив организовал частное ателье, которое проектирует, производит и продает оптом верхнюю одежду. Фирма современная, персонал амбициозный, работают хорошо, а потому клиентов много. Естественно, без применения автоматизации все это не решается. Имеется, в частности, торговая система, которая учитывает движение товарных и денежных средств. Ежедневно в базу данных вводятся десятки счетов, накладных, заказов и других документов. В течение какого-то времени с этими документами сотрудники активно работают. Бухгалтерия за счетами следит. Склад выдает и заказывает сырье. Сотрудники кроят и шьют по введенным в бланк заказа размерам. После того как документ закончил свой жизненный цикл, он в рамках торговой системы больше никак не используется.
На основе циркулирующей в системе информации руководство анализирует деятельность, намечает пути устранения недостатков и увеличения достоинств. Аналитика производится как самой системой автоматически, так и уполномоченными сотрудниками в ручном режиме, на основе стандартизированных в рамках фирмы отчетов и выборок, генерируемых базой данных.
Со временем, по мере накопления информации, система сильно разбухает, так как устаревшие данные продолжают храниться в системе для всяких прочих надобностей. Растущий объем данных начинает замедлять выполнение операций, что порождает естественное желание администратора избавиться от старых документов. Однако достаточно толковый руководитель понимает что собранный архив вовсе не является пустым балластом. Это ценнейший материал для анализа с целью выявления всевозможных средне- и долгосрочных тенденций. А если еще объединить данные торговой системы с данными из других систем предприятия - анализ может быть гораздо более глубоким. Данные, накопленные в предприятии, - уникальный ресурс, который абсолютно недоступен конкурентам. Итак, руководитель приглашает или выращивает в своей фирме аналитика, который хочет извлечь из данных все, что можно. Например, понять, какой тип клиентов наиболее перспективен для фирмы или какие скидки будут оптимальными этой весной. Но сделать это оказывается не так-то просто.
Торговая система является типичным представителем т.н. оперативных систем или систем оперативной обработки транзакций. Эти системы рассчитаны на интенсивный ввод и обновление информации, причем операции с данными затрагивают, как правило, единичные записи. Структура базы данных оперативных систем в высокой степени нормализована, т.е. состоит из множества узких таблиц, связанных между собой отношениями внешних ключей. Такая нормализованная структура оптимизирована именно для быстрого поиска и обработки единичных записей.
Однако на практике подобная идеология оказывается не совсем удобной. Все дело в том, что система хранит лишь исходный фактический материал, а все остальные выборки строит по мере возникновения нужды в них. Таким образом, даже самая элементарная справка вызывает достаточно длительный процесс обсчета исходного массива данных, что требует значительных расходов времени. С подобным вполне можно мириться, когда речь не идет о большом количестве справок либо когда процесс может выполняться не в масштабе реального времени. Предположим, тот же финансовый директор вовсе не каждые две минуты требует всеобъемлющий финансовый анализ хозяйственной деятельности предприятия. В лучшем случае он нужен один-два раза в день, например, утром и вечером. Поэтому перегрузка системы, вызываемая, в частности, блокировкой исходных таблиц на время выполнения запроса, возникает редко и на деятельности других зависимых от той же информации подразделений сказывается мало.
Однако существует и другая сторона медали. Любая система строится исходя из конкретной модели взаимосвязей данных и связанных с этим видов ее представления. Так, отдел розничных продаж оперирует штуками и прочими квадратными метрами, в то время как служба обеспечения озабочена вместимостью транспортных единиц (к примеру, вагонов) и оперирует кубическими метрами, декалитрами и регистровыми тоннами. Таким образом, аналитик сталкивается с ситуацией, когда требующаяся ему информация не существует в единой форме представления, разрознена и зачастую вообще не доступна для единовременного отображения. Чтобы получить желаемый результат, он вынужден заново формировать собственные структуры запросов, приводить данные к единому виду и только потом уже анализировать их. На все это уходит львиная доля ресурсов и времени, что едва ли можно признать допустимым.
Проблемы аналитика может решить наличие информационной системы, предназначенной и оптимизированной для выполнения его функций анализа данных. Неоднократные теоретические и практические исследования показали, что попытки сочетать в одной системе оперативные и информационные функции хороших результатов не дают. Информационная система должна строиться на особой структуре хранилища данных.
Хранилище данных (Data Warehouse) - это предметно-ориентированное, интегрированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений. Предмето-ориентированность означает, что данные в хранилище организованы вокруг существенных аспектов деятельности фирмы: товар, покупатель, продажа и т.д. (а не узких атрибутов бизнес-процесса: счет, накладная, прайс-лист). Интегрированность означает, что одни и те же по смыслу данные, полученные из разных оперативных систем, в хранилище именуются и выражаются единым образом, независимо от того, насколько по-разному они хранились в "породивших" их оперативных системах. Привязанность ко времени означает, что хранилище можно рассматривать как "историю" данных: можно восстановить картину на любой момент времени. Атрибут времени всегда явно присутствует в структурах данных хранилища. Неизменяемость означает, что, попав однажды в хранилище, данные уже не изменяются, в отличие от оперативных систем, где данные обязаны присутствовать только "в последней версии", поэтому постоянно меняются. В хранилище данные только добавляются.
В настоящее время идеология "хранилища данных" продолжает активно совершенствоваться с целью получения наиболее оптимальных моделей, сочетающих в себе высокую степень оперативной гибкости при минимизации требуемых ресурсов, как временных, так и вычислительных. В идеале предполагается достичь такого уровня организации, при котором система была бы в состоянии самостоятельно генерировать критерии анализа исходя из поступившего общего запроса. Сюжеты фантастических романов, когда человек обращается к компьютеру на естественном языке с вопросом типа - насколько надежны такие-то акции в ближайшие три года, вовсе не так уж и фантастичны на самом деле. Достаточно подробно о современном состоянии "хранилищ данных" рассказывается на сервере Центра Информационных технологий (citforum.rb.ru/database/ kbd98/glava15.shtml).
Если от теории перейти к практике, то для построения такого хранилища, отвечающего потребностям конкретного предприятия или процесса, имеет смысл обратиться к инструментарию ведущих разработчиков в данной области, продуктам компаний Oracle, Hewlett Packard, NCR, Informix Software, SAS Institute, Sybase и других.
Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих: наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных; существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных; высокий технологический потенциал компании в области анализа данных; доступность ряда продуктов, производимых другими компаниями.
Работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.
Решение компании NCR направлено на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.
Стратегия компании Informix Software в отношение хранилищ данных направлена на расширение рынка для ее продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура хранилища данных базируется на четырех технологиях: реляционных базах данных, программном обеспечении для управления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных.
Компания SAS Institute считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем: обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и нереляционных); преобразование данных и манипулирование ими с использованием 4GL; наличие сервера многомерных баз данных; большой набор методов и средств для аналитической обработки и статистического анализа.
Стратегия компании Sybase в области хранилищ данных основывается на разработанной ею архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).
В то же время не лишним будет отметить, что перечисленные выше подходы и программные продукты ориентированы в первую очередь на потребности очень больших корпораций, хотя с их помощью вполне можно решать и менее масштабные задачи, соответствующие уровню средних отечественных предприятий. По большому счету, если тут будет уместным подобное сравнение, они реализованы для принципа "посмотрел-выстрелил-посмотрел". То есть для тех случаев, когда поступление, обработка, анализ данных, а также принятие и реализация решения на основе такого анализа, должны происходить в так называемом "реальном масштабе времени". Например, для создания системы информационной поддержки деятельности банковской службы, управляющей портфелем акций. Ее работа заключается в том, чтобы одновременно с получением данных по котировкам определенных ценных бумаг и на основе другой быстроменяющейся информации делать выводы о целесообразности вложения средств в эти бумаги и проведения операций по их непосредственному вложению. Временная задержка на любом из этапов процесса может привести к фатальным последствиям. Например, маклер увидел наметившуюся тенденцию падения курса имеющихся у него акций, однако пока распоряжение об их продаже дошло до исполнителя и было выполнено, "поезд уже ушел".
Естественно, далеко не везде требуется такая оперативность. Стало быть существует достаточно огромный круг задач, который может быть вполне успешно решен и в рамках систем управления базами данных (СУБД). Пройдя большой путь, они значительно расширили свои возможности и даже приобрели своего рода специализацию, что позволило перекрыть весь спектр задач, от частного пользования и вовсе уж крошечных индивидуальных предприятий до фирм, по своим параметрам занимающих промежуточное положение между понятиями "малый" и "большой" бизнес.
Перед тем как приступить к непосредственному выбору инструментария, обсуждению его достоинств и недостатков, имеет смысл сначала задуматься над тем, а что собственно вообще желается достичь? Как показывает практика, ошибка в стратегии или модели становится очевидной и, как правило, непреодолимой лишь после того, как выполнено около семидесяти процентов работ и затрачено около двух третей отведенного на проект времени. Естественно, в подобной ситуации разработчик не имеет другого выбора, кроме как либо начать все с начала, либо отказаться от реализации части функций, запланированных изначально. Оба подхода приводят к одинаковому результату - к заметному ухудшению потребительских свойств готовой системы. Чтобы детальнее представить себе этот аспект проблемы, будет не лишним обратиться к материалу "ПРОЕКТИРОВАНИЕ СКЛАДА ДАННЫХ" (www.argussoft.ru/as_cpwin/article5.htm).
Когда ожидаемая система, наконец, приобретет законченные очертания, наступает пора разработки архитектуры СУБД (www.citforum.ru/database/dbguide/1-3.shtml), от оптимальности которой непосредственно зависит эффективность всего инструмента в целом.
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
- физическом размещении в памяти данных и их описаний;
- механизмах поиска запрашиваемых данных;
- проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
- способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
- поддержании баз данных в актуальном состоянии и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных. Сам проект начинается с подробного описания требований к ней со стороны отдельных ее пользователей, начиная с самого нижнего звена и заканчивая высшим. Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей и свои представления о данных, которые могут потребоваться в будущих приложениях, разработчик сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных. Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область. Остальные модели являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое разработчиком по инфологической модели данных, называют даталогической моделью данных. Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. Можно при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. Можно подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же, как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Далее уже наступает этап конкретизации инструментария, с помощью которого будут в дальнейшем "писать" конкретную базу согласно разработанной модели. В этом отношении представляется весьма не лишним посетить обзорную страницу основных параметров наиболее распространенных современных СУБД (DBMS Database Management Systems) (www.pvl.kz/yellow/3/7/index.htm). Она включает описания большого количества разнообразных инструментов, в том числе: Adabas; Angara; DataFlex; DataX; DB2; dSALVAGE Professional; Empress ; FirstSQL; Goldmedal; Informix Dynamic Server и Informix-SE; InterBase; Jasmine; Microsoft Access; Microsoft SQL Server; ObjectStore; OpenIngres и OpenROAD; ORACLE Servers; PostgreSQL; Progress RDBMS; R:BASE; SQLBase; SUPRA Server; Sybase SQL Server; Universal Compiler; Visual dBASE; Visual FoxPro.
Вполне понятно, что все вышеперечисленное выглядит несколько устрашающе и может отпугнуть начинающего разработчика. Не говоря уже об иных руководителях предприятий, выступающих в роли заказчика. В нашей стране как-то привыкли, что дело заказчика - заказывать, а разработчика - понимать недосказанности и перекладывать их на строгий язык программирования. Увы, подобные времена уходят в прошлое. Если нужен некий специализированный инструмент, то его конечный вид будет напрямую зависеть от того, насколько тесно взаимодействовали стороны на этапе создания такого инструмента. А для плодотворного сотрудничества стороны, как минимум, должны разговаривать на одном языке. Это вовсе не означает, что заказчик обязан быть программистом, а программист - специалистом в области деятельности заказчика. Однако определенная близость подходов должна существовать, ибо в противном случае получится классический "испорченный телефон", как, например, вопрос, который задал наш читатель (см. в начале).
Александр Запольскис
leshy@nestor.minsk.by - титульная страница
Подскажите пожалуйста, наиболее дешевый способ хранения огромных массивов информации. Скорость передачи данных и время доступа не имеет значения.
Из письма Александра, читателя КГ.
Что же, отчего не порадеть хорошему человеку. Тем более, что вопрос, в общем-то, интересный. Правда, сформулирован очень уж странно. Как только речь заходит об огромных массивах информации такие моменты, как время и удобство доступа, а также скорость передачи информации, приобретают весьма даже важную роль. Кроме того, само понятие дешевизны приобретает конкретный смысл лишь после учета всех параметров. Теоретически возможно построить на базе Microsoft Access систему электронных торгов, например, ценными бумагами, в реальном времени. Однако, чтобы результат стал работать согласно с возлагаемыми на него ожиданиями, понадобится весьма и весьма производительное оборудование. С другой стороны, хранилище данных, опять же теоретически, возможно построить на базе нескольких допотопных PC/XT, однако скорость работы окажется недопустимо низкой. В обоих случаях в разработках не будет никакого смысла, что полностью лишит их практической пользы, а следовательно и какой-либо цены.
В общем, короткого практического совета, чего-нибудь в стиле - пишите на дискеты, увы, не получится. Слишком мало исходной информации. Зато появляется прекрасный повод рассмотреть вопрос хранения данных вообще, и как явление, и как процесс.
По большому счету вопрос оперирования большим массивом данных существует лишь в двух аспектах: либо есть некий большой массив, который необходимо хранить без изменения достаточно длительный промежуток времени, либо есть некий продолжительный процесс, функционирование которого непосредственным образом связано с приемом, обработкой и выдачей информации.
Примером первого варианта может служить обыкновенная электронная библиотека. Конечно, рекламный трюк, демонстрирующий на одной чаше весов высокую кипу бумаги, а на второй - маленький серебристый компакт-диск, производит впечатление. Однако даже такая библиотека, как "пушкинка", туда не уместится. Что уж тут говорить об объеме библиотеке имени Ленина или библиотеке Конгресса. Будучи перенесенными на компакт-диски, они займут достаточно мало места и вполне уместятся в обычной тумбочке под письменным столом. Таким образом, при условии, что пользоваться ею будет всего один человек, все, что необходимо, это надежный носитель и корректно составленная таблица, например, в Microsoft Excel, с полным библиотечным перечнем. Возможно, пример и не совсем корректен, однако он более чем наглядно демонстрирует специфику момента.
Примером второго является работа любой торговой фирмы. Спецификация и цена закупки, номенклатура поступления на склад, накладные на отгрузку, гарантийные ведомости, счета и прочая бухгалтерская информация - все это неразрывно связано с жизнедеятельностью предприятия. Причем важную роль играет буквально каждый этап, от ввода и обработки данных, до вывода статистики и аналитических сводок. Тут уже одним приводом CD-ROM не обойтись.
В общем, если "огромный массив информации" - это просто объемный отсканированный с высоким разрешением фотоальбом, то решением задачи является выбор соответствующего носителя данных из имеющихся на рынке устройств данного класса, а их не так уж и много.
Флоппи дисковод LS-120 формата 3.5 дюйма на 120 Mб (www.parad.ru/txt/DAS/ADrive.htm) придуман не так уж и давно, чуть более полутора лет назад. Однако за прошедшее время устройство значительно усовершенствовалось в техническом плане и резко подешевело в ценовом отношении. Еще летом этого года я видел его в Минске по цене чуть менее ста долларов. Сегодня подобные игрушки производят многие компании, самая известная из которых - SONY. Система LS-120 интересна тем, что чрезвычайно похожа на обычный трехдюймовый дисковод как по методике пользования, так и по принципу применения. Накопитель LS-120 монтируется в обычный отсек для внешних устройств половинной высоты и подключается к шине IDE.
А вот дальше начинаются нюансы. Дело в том, что LS-120 оперирует двумя типами носителей: обычной трехдюймовой дискетой емкостью 1,44 Мб и собственным специализированным картриджем емкостью 120 Мб. Что это дает - не мне вам объяснять.
Формативная емкость
| LS-120 | 120 Мб |
| HD | 1,44 Мб |
| DD | 720 Кб |
| Метод записи | RLL (1,7) |
| Плотность дорожки (дор./дюйм) | 2,490 |
| Плотность записи (байт/дюйм) | 44,880 |
| Размер сектора (байт) | 512 |
| Число секторов в дорожке | 51-92 |
| Интерфейс | ATAPI IDE\ |
| Рабочие характеристики | |
| Скорость передачи (в/из буфера) | 4 Мб/сек |
| Скорость поиска дорожки (мс) | 6 |
| Средняя скорость поиска (мс) | 65 |
| Время запуска (мс) | 250 |
| Время остановки (мс) | 50 |
| Температура эксплуатации | 5-50 град. |
| Питание | +5 vdc +/- 5% |
| Питания (макс.) | +5 vdc, 1,3 A |
| Потребляемая мощность | |
| При 100% нагрузке | 5,5 ватт |
| В режиме ожидания | 1,5 ватт |
| Средняя потребляемаямощность | 1,7 ватт |
| Сертификаты | FCC Класс В, CSA, TUV/VDE, CE |
Вторым неплохим аппаратным вариантом решения задачи хранения больших объемов данных может оказаться накопитель с несколько несерьезным наименованием JAZ (www.parad.ru/txt/DAS/ Jaz.htm), предлагаемый фирмой Iomega. Несколько отличаясь по технологии чтения/записи от LS-120, накопитель JAZ позволяет оперировать значительно большими объемами, до 1 Гб. Без использования алгоритма сжатия данных "один гиг" перекачивается примерно за пять минут. За счет компрессии емкость увеличивается в два раза, но и время доступа увеличивается.
| Емкость носителя информации | Используется Jaz-диск емкостью1070 Мб |
| Интерфейс | Fast SCSI-2 |
| Среднее время поиска | 10 миллисекунд - чтение, 12 миллисекунд - запись |
| Скорость передачи данных | 10 Мб/с |
| Скорость вращения шпинделя | 5400 об/мин |
| Совместимость | DOS, Windows 95, Windows NT, OS/2,Mac OS |
Если массив в перспективе предполагается носить (например, в дипломате с работы домой и обратно), то имеет смысл обратить более пристальное внимание на накопители Zip (www.parad.ru/txt/ DAS/Zip.htm) от все той же Iomega. При емкости картриджа от ста до двухсот мегабайт, устройство (во внешнем исполнении) отличается компактностью и низким весом (450 грамм). Кроме того, накопитель Zip, в отличие от всех остальных, позволяет использовать его в качестве основного носителя данных при работе с программным обеспечением наравне с привыч-ным уже жестким диском.
Накопители lomega ZIP выпускаются во внутреннем (интерфейс SCSI и ATAPI) и внешнем (интерфейс SCSI) исполнении. Внутренний ZIP легко устанавливается в любой 3.5" или 5.25" разъём вашего компьютера. Внутренний Zip SCSI подключается к поставляемому в комплекте Zip Zoom SCSI акселератору, который максимально ускоряет работу накопителя. Zip-ATAPI подключается аналогично CD-ROM, IDE НЖМД и т.д. Zip-параллельный порт подключается непосредственно к разъёму параллельного порта. При этом он обладает "прозрачностью" для принтера, что позволяет использовать и принтер, и Zip, не переключая постоянно кабели.
| Емкость носителя информации | Используется Zip-диск емкость 100 Мб |
| Интерфейс | SCSI-2 (внутреннее и внешнее исполнение) |
| Параллельный порт (внутреннее исполнение) | IDE (АTAPI) (внутреннее исполнение) |
| Среднее время поиска | 29 миллисекунд |
| Скорость передачи данных | 1.4 Мб/с |
| Пропускная способность | до 60 Мб/мин (SCSI интерфейс) |
| до 20 Мб/мин (параллельный порт) | |
| до 26.7 Мбит/с (интерфейс ATAPI) | |
| Скорость вращения шпинделя | 2945 об/мин |
| Совместимость | DOS, Windows 95, Windows NT, OS/2, Mac OS |
Все, что выходит за рамки столь простых технических решений и призвано не только хранить, но активно обрабатывать большие массивы информации, попадает в другую категорию, именуемую "хранилища данных" (www.ci.ru/inform7_97/astr1.htm). Предположим, для примера, что некоторый творческий коллектив организовал частное ателье, которое проектирует, производит и продает оптом верхнюю одежду. Фирма современная, персонал амбициозный, работают хорошо, а потому клиентов много. Естественно, без применения автоматизации все это не решается. Имеется, в частности, торговая система, которая учитывает движение товарных и денежных средств. Ежедневно в базу данных вводятся десятки счетов, накладных, заказов и других документов. В течение какого-то времени с этими документами сотрудники активно работают. Бухгалтерия за счетами следит. Склад выдает и заказывает сырье. Сотрудники кроят и шьют по введенным в бланк заказа размерам. После того как документ закончил свой жизненный цикл, он в рамках торговой системы больше никак не используется.
На основе циркулирующей в системе информации руководство анализирует деятельность, намечает пути устранения недостатков и увеличения достоинств. Аналитика производится как самой системой автоматически, так и уполномоченными сотрудниками в ручном режиме, на основе стандартизированных в рамках фирмы отчетов и выборок, генерируемых базой данных.
Со временем, по мере накопления информации, система сильно разбухает, так как устаревшие данные продолжают храниться в системе для всяких прочих надобностей. Растущий объем данных начинает замедлять выполнение операций, что порождает естественное желание администратора избавиться от старых документов. Однако достаточно толковый руководитель понимает что собранный архив вовсе не является пустым балластом. Это ценнейший материал для анализа с целью выявления всевозможных средне- и долгосрочных тенденций. А если еще объединить данные торговой системы с данными из других систем предприятия - анализ может быть гораздо более глубоким. Данные, накопленные в предприятии, - уникальный ресурс, который абсолютно недоступен конкурентам. Итак, руководитель приглашает или выращивает в своей фирме аналитика, который хочет извлечь из данных все, что можно. Например, понять, какой тип клиентов наиболее перспективен для фирмы или какие скидки будут оптимальными этой весной. Но сделать это оказывается не так-то просто.
Торговая система является типичным представителем т.н. оперативных систем или систем оперативной обработки транзакций. Эти системы рассчитаны на интенсивный ввод и обновление информации, причем операции с данными затрагивают, как правило, единичные записи. Структура базы данных оперативных систем в высокой степени нормализована, т.е. состоит из множества узких таблиц, связанных между собой отношениями внешних ключей. Такая нормализованная структура оптимизирована именно для быстрого поиска и обработки единичных записей.
Однако на практике подобная идеология оказывается не совсем удобной. Все дело в том, что система хранит лишь исходный фактический материал, а все остальные выборки строит по мере возникновения нужды в них. Таким образом, даже самая элементарная справка вызывает достаточно длительный процесс обсчета исходного массива данных, что требует значительных расходов времени. С подобным вполне можно мириться, когда речь не идет о большом количестве справок либо когда процесс может выполняться не в масштабе реального времени. Предположим, тот же финансовый директор вовсе не каждые две минуты требует всеобъемлющий финансовый анализ хозяйственной деятельности предприятия. В лучшем случае он нужен один-два раза в день, например, утром и вечером. Поэтому перегрузка системы, вызываемая, в частности, блокировкой исходных таблиц на время выполнения запроса, возникает редко и на деятельности других зависимых от той же информации подразделений сказывается мало.
Однако существует и другая сторона медали. Любая система строится исходя из конкретной модели взаимосвязей данных и связанных с этим видов ее представления. Так, отдел розничных продаж оперирует штуками и прочими квадратными метрами, в то время как служба обеспечения озабочена вместимостью транспортных единиц (к примеру, вагонов) и оперирует кубическими метрами, декалитрами и регистровыми тоннами. Таким образом, аналитик сталкивается с ситуацией, когда требующаяся ему информация не существует в единой форме представления, разрознена и зачастую вообще не доступна для единовременного отображения. Чтобы получить желаемый результат, он вынужден заново формировать собственные структуры запросов, приводить данные к единому виду и только потом уже анализировать их. На все это уходит львиная доля ресурсов и времени, что едва ли можно признать допустимым.
Проблемы аналитика может решить наличие информационной системы, предназначенной и оптимизированной для выполнения его функций анализа данных. Неоднократные теоретические и практические исследования показали, что попытки сочетать в одной системе оперативные и информационные функции хороших результатов не дают. Информационная система должна строиться на особой структуре хранилища данных.
Хранилище данных (Data Warehouse) - это предметно-ориентированное, интегрированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений. Предмето-ориентированность означает, что данные в хранилище организованы вокруг существенных аспектов деятельности фирмы: товар, покупатель, продажа и т.д. (а не узких атрибутов бизнес-процесса: счет, накладная, прайс-лист). Интегрированность означает, что одни и те же по смыслу данные, полученные из разных оперативных систем, в хранилище именуются и выражаются единым образом, независимо от того, насколько по-разному они хранились в "породивших" их оперативных системах. Привязанность ко времени означает, что хранилище можно рассматривать как "историю" данных: можно восстановить картину на любой момент времени. Атрибут времени всегда явно присутствует в структурах данных хранилища. Неизменяемость означает, что, попав однажды в хранилище, данные уже не изменяются, в отличие от оперативных систем, где данные обязаны присутствовать только "в последней версии", поэтому постоянно меняются. В хранилище данные только добавляются.
В настоящее время идеология "хранилища данных" продолжает активно совершенствоваться с целью получения наиболее оптимальных моделей, сочетающих в себе высокую степень оперативной гибкости при минимизации требуемых ресурсов, как временных, так и вычислительных. В идеале предполагается достичь такого уровня организации, при котором система была бы в состоянии самостоятельно генерировать критерии анализа исходя из поступившего общего запроса. Сюжеты фантастических романов, когда человек обращается к компьютеру на естественном языке с вопросом типа - насколько надежны такие-то акции в ближайшие три года, вовсе не так уж и фантастичны на самом деле. Достаточно подробно о современном состоянии "хранилищ данных" рассказывается на сервере Центра Информационных технологий (citforum.rb.ru/database/ kbd98/glava15.shtml).
Если от теории перейти к практике, то для построения такого хранилища, отвечающего потребностям конкретного предприятия или процесса, имеет смысл обратиться к инструментарию ведущих разработчиков в данной области, продуктам компаний Oracle, Hewlett Packard, NCR, Informix Software, SAS Institute, Sybase и других.
Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих: наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных; существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных; высокий технологический потенциал компании в области анализа данных; доступность ряда продуктов, производимых другими компаниями.
Работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.
Решение компании NCR направлено на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.
Стратегия компании Informix Software в отношение хранилищ данных направлена на расширение рынка для ее продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура хранилища данных базируется на четырех технологиях: реляционных базах данных, программном обеспечении для управления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных.
Компания SAS Institute считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем: обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и нереляционных); преобразование данных и манипулирование ими с использованием 4GL; наличие сервера многомерных баз данных; большой набор методов и средств для аналитической обработки и статистического анализа.
Стратегия компании Sybase в области хранилищ данных основывается на разработанной ею архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).
В то же время не лишним будет отметить, что перечисленные выше подходы и программные продукты ориентированы в первую очередь на потребности очень больших корпораций, хотя с их помощью вполне можно решать и менее масштабные задачи, соответствующие уровню средних отечественных предприятий. По большому счету, если тут будет уместным подобное сравнение, они реализованы для принципа "посмотрел-выстрелил-посмотрел". То есть для тех случаев, когда поступление, обработка, анализ данных, а также принятие и реализация решения на основе такого анализа, должны происходить в так называемом "реальном масштабе времени". Например, для создания системы информационной поддержки деятельности банковской службы, управляющей портфелем акций. Ее работа заключается в том, чтобы одновременно с получением данных по котировкам определенных ценных бумаг и на основе другой быстроменяющейся информации делать выводы о целесообразности вложения средств в эти бумаги и проведения операций по их непосредственному вложению. Временная задержка на любом из этапов процесса может привести к фатальным последствиям. Например, маклер увидел наметившуюся тенденцию падения курса имеющихся у него акций, однако пока распоряжение об их продаже дошло до исполнителя и было выполнено, "поезд уже ушел".
Естественно, далеко не везде требуется такая оперативность. Стало быть существует достаточно огромный круг задач, который может быть вполне успешно решен и в рамках систем управления базами данных (СУБД). Пройдя большой путь, они значительно расширили свои возможности и даже приобрели своего рода специализацию, что позволило перекрыть весь спектр задач, от частного пользования и вовсе уж крошечных индивидуальных предприятий до фирм, по своим параметрам занимающих промежуточное положение между понятиями "малый" и "большой" бизнес.
Перед тем как приступить к непосредственному выбору инструментария, обсуждению его достоинств и недостатков, имеет смысл сначала задуматься над тем, а что собственно вообще желается достичь? Как показывает практика, ошибка в стратегии или модели становится очевидной и, как правило, непреодолимой лишь после того, как выполнено около семидесяти процентов работ и затрачено около двух третей отведенного на проект времени. Естественно, в подобной ситуации разработчик не имеет другого выбора, кроме как либо начать все с начала, либо отказаться от реализации части функций, запланированных изначально. Оба подхода приводят к одинаковому результату - к заметному ухудшению потребительских свойств готовой системы. Чтобы детальнее представить себе этот аспект проблемы, будет не лишним обратиться к материалу "ПРОЕКТИРОВАНИЕ СКЛАДА ДАННЫХ" (www.argussoft.ru/as_cpwin/article5.htm).
Когда ожидаемая система, наконец, приобретет законченные очертания, наступает пора разработки архитектуры СУБД (www.citforum.ru/database/dbguide/1-3.shtml), от оптимальности которой непосредственно зависит эффективность всего инструмента в целом.
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
- физическом размещении в памяти данных и их описаний;
- механизмах поиска запрашиваемых данных;
- проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
- способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
- поддержании баз данных в актуальном состоянии и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных. Сам проект начинается с подробного описания требований к ней со стороны отдельных ее пользователей, начиная с самого нижнего звена и заканчивая высшим. Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей и свои представления о данных, которые могут потребоваться в будущих приложениях, разработчик сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных. Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область. Остальные модели являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое разработчиком по инфологической модели данных, называют даталогической моделью данных. Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. Можно при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. Можно подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же, как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Далее уже наступает этап конкретизации инструментария, с помощью которого будут в дальнейшем "писать" конкретную базу согласно разработанной модели. В этом отношении представляется весьма не лишним посетить обзорную страницу основных параметров наиболее распространенных современных СУБД (DBMS Database Management Systems) (www.pvl.kz/yellow/3/7/index.htm). Она включает описания большого количества разнообразных инструментов, в том числе: Adabas; Angara; DataFlex; DataX; DB2; dSALVAGE Professional; Empress ; FirstSQL; Goldmedal; Informix Dynamic Server и Informix-SE; InterBase; Jasmine; Microsoft Access; Microsoft SQL Server; ObjectStore; OpenIngres и OpenROAD; ORACLE Servers; PostgreSQL; Progress RDBMS; R:BASE; SQLBase; SUPRA Server; Sybase SQL Server; Universal Compiler; Visual dBASE; Visual FoxPro.
Вполне понятно, что все вышеперечисленное выглядит несколько устрашающе и может отпугнуть начинающего разработчика. Не говоря уже об иных руководителях предприятий, выступающих в роли заказчика. В нашей стране как-то привыкли, что дело заказчика - заказывать, а разработчика - понимать недосказанности и перекладывать их на строгий язык программирования. Увы, подобные времена уходят в прошлое. Если нужен некий специализированный инструмент, то его конечный вид будет напрямую зависеть от того, насколько тесно взаимодействовали стороны на этапе создания такого инструмента. А для плодотворного сотрудничества стороны, как минимум, должны разговаривать на одном языке. Это вовсе не означает, что заказчик обязан быть программистом, а программист - специалистом в области деятельности заказчика. Однако определенная близость подходов должна существовать, ибо в противном случае получится классический "испорченный телефон", как, например, вопрос, который задал наш читатель (см. в начале).
Александр Запольскис
leshy@nestor.minsk.by - титульная страница
Компьютерная газета. Статья была опубликована в номере 39 за 1998 год в рубрике интернет :: разное
