Оглавление

Аппаратные средства.. 3

Конфигурация компьютера. 3

Расшифровка конфигурации персонального компьютера. 3

Анализ конфигурации компьютера. 4

Оснащение компьютерами магазина одежды “Экстра”. 5

Базы данных в экономических системах. Вопросы разработки и внедрения баз данных.. 6

Проектирование и внедрение баз данных. 7

Список литературы... 16


 

 

 

 

 

 

 

 

Аппаратные средства


Конфигурация компьютера

AMD Athlon 900 / 64 Mb SD RAM / HDD 10 Gb UDMA Fujitsu / ZIDA VIA 693, 1 AGP, 4 PCI / S3-Trio 3D AGP 4 Mb, Genius Easy Mouse, Keyboard, 2 COM, 2 USB, CD-ROM Acer 48-x, 15’’ LG Workstation 56E, Lexmark Color JP Z12, Zyxel Prestige 681


Расшифровка конфигурации персонального компьютера

§  AMD Athlon 900 – процессор Athlon с тактовой частотой 900 мГц. Приблизительная цена 700 рублей.

§  64 Mb SDRAM – оперативная память объемом 64 Мб, типа DIMM SDRAM. Приблизительная цена 300 рублей.

§  HDD 10 Gb UDMA Агошеыг – жесткий диск объемом 10 Гб фирмы Fujitsu, поддерживающий технологию Ultra Direct Memory Access. Приблизительная цена 700 рублей.

§  ZIDA VIA 693, 1 AGP, 4 PCI – материнская плата. Имеет AGP-слот и 4 PCI-слота. Приблизительная цена 1500 рублей.

§  S3-Trio 3D AGP 4 Mb – видеокарта с видеопамятью объемом 4 Мб. Приблизительная цена 100 рублей.

§  Genius Easy Mouse – мышь фирмы Genius. Приблизительная цена 60 рублей.

§  Keyboard – стандартная клавиатура неизвестной фирмы. Приблизительная цена – 100-150 р.

§  2 COM – говорит о том, что на материнской плате имеется 2 последовательный порта.

§  2 USB – говорит о том, что на материнской плате имеется 2 порта USB.

§  CD-ROM Acer 48-x – CD-ROM фирмы Acer скоростью 48x. Цена 700 рублей.

§  15’’ LG Workstation 56E – 15-тидюймовый монитор фирмы LG. Приблизительная цена 3500 рублей.

§  Lexmark Color JP Z12 – струйный принтер фирмы Lexmark. Приблизительная цена 2000 рублей.

§  Zyxel Prestige 681 – модем фирмы Zyxel. Приблизительная цена – 1500 рублей.


Цены взяты из прайс-листов компьютерных фирм “Интерлинк” и “Арси-ситек”. Но большинство комплектующих, перечисленных выше давно не выпускаются и не продаются в фирмах новыми. В таком случае цены были взяты в среднем из газетных объявлений о продаже комплектующих.


Анализ конфигурации компьютера

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

§  Слишком устаревшая видеокарта объемом 4 мегабайта. Она позволит использовать компьютер только как офисную машину. Практически все игры, выпускаемые сейчас требуют наличия более мощной видеосистемы.

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


Оснащение компьютерами магазина одежды “Экстра”.

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

Компьютеры оснащены обычным операционной системой Microsoft Windows XP  и пакетом Microsoft Office XP.


§  Системный блок INTEL Celeron 1700 / 256Mb / HDD 40Gb (7200) / 3.5" / Micro-Star (GeForce4 MX440)+TV / CDROM. Цена 10274 р.

§  Monitor 15" Monitor 15" RoverScan  115GS. Цена 3895 р.

§  Принтер HP LaserJet 1010. Цена 6150 р.


Итого:

2 системных блока + 2 монитора + 1 принтер = 34448 р.

По данным прайс-листа компании “Арси-ситек”.


Базы данных в экономических системах. Вопросы разработки и внедрения баз данных

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

Несмотря на то, что реляционные СУБД давно и прочно заня­ли основные позиции на рынке программного обеспечения по обработке данных, в этой области остается много нерешенных про­блем. Во-первых, это касается нового стандарта языка запросов SQL-3, воз­можности которого должны быть расширены за счет работы с объектами и расширения типов обрабатываемых данных (большие массивы текстовых данных, графические объекты, слабо структурированные объекты и т.д.). Во-вторых, движение в сторону открытых систем предполагает пере­смотр организации серверов баз данных. В-третьих, обозначилась проблема использования старых баз данных в рамках новых программных продуктов.

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

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

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


Проектирование и внедрение баз данных

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

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

Такое представление уровней данных не единственное. Существуют и другие варианты многоуровневого представления данных. Так, в соответствии с предложениями исследовательской группы по системам управления данными Американского национального института стандартов ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:

§  внешний уровень (с точки зрения конечного пользователя и прикладного программиста);

§  концептуальный уровень (с точки зрения СУБД);

§  внутренний уровень (с точки зрения системного программиста).

В соответствии с этой концепцией внешний уровень - это часть (подмножество) концептуальной модели, необходимая для реализации какого-либо запроса или прикладной программы. То есть, если концептуальная модель выступает как схема, поддерживаемая конкретной СУБД, то внешний уровень — это некоторая совокупность подсхем, необходимых для реализации конкретной прикладной программы или запроса пользователя.

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

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

При проектировании БД на внешнем уровне необходимо изучить функционирование объекта управления, например, какого-либо экономического предприятия, для которого проектируется БД, всю первичную и выходную документацию с точки зрения определения того, какие именно данные необходимо сохранять в базе данных. Внешний уровень это, как правило, словесное описание входных и выходных сообщений, а также данных, которые целесообразно сохранять в БД. [2]Описание внешнего уровня не исключает наличия элементов дублирования, избыточности и несогласованности данных. Поэтому для устранения этих аномалий и противоречий внешнего описания данных выполняется инфологическое проектирование. Инфологическая модель является средством структуризации предметной области и понимания концепции семантики данных. Инфологическую модель можно рассматривать в основном как средство документирования и структурирования формы представления информационных потребностей, которая обеспечивает непротиворечивое общение пользователей и разработчиков системы.

Все внешние представления интегрируются на инфологическом уровне, где формируется инфологическая (каноническая) модель данных, которая не является простой суммой внешних представлений данных.

Инфологический уровень представляет собой информационно-логическую модель (ИЛМ) предметной области, из которой исключена избыточность данных и отображены информационные особенности объекта управление без учета особенностей и специфики конкретной СУБД. То есть инфологическое представление данных ориентированно преимущественно на человека, который проектирует или использует базу данных.

Логический (концептуальный) уровень построен с учетом специфики и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической.[3]

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

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

От параметров физической модели зависят такие характеристики функционирования БД: объем памяти и время реакции системы. Физические параметры БД можно изменять в процессе ее эксплуатации с целью повышения эффективности функционирование системы. Изменение физических параметров не предопределяет необходимости изменения инфологической и даталогической моделей.

Схема взаимосвязи уровней представления данных в БД изображена на рисунке ниже. В соответствии с этими уровнями проектируется БД. Проектирование БД экономической системы — это сложный и трудоемкий процесс, который требует привлечения многих высококвалифицированных специалистов в области предметной области, а также в области проектирования БД. От того, насколько квалифицированно спроектирована БД, зависят производительность информационной системы и полнота обеспечения функциональных потребностей пользователей и прикладных программ. Неудачно спроектированная БД может усложнить процесс разработки прикладного программного обеспечения, обусловить необходимость использования более сложной логики, которая, в свою очередь, увеличит время реакции системы, а в дальнейшем может привести к необходимости перепроектирования логической модели БД. Реструктуризация или внесение изменений в логическую модель БД это очень нежелательный процесс, поскольку он является причиной необходимости модификации или даже перепрограммирование отдельных задач.

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

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

При создании как экономических, так и других систем существуют два подхода к проектированию баз данных на внешнем уровне: «от предметной области» и «от запроса». Подход «от предметной области» состоит в том, что формируется внешнее информационное обеспечение всей предметной области без учета потребностей пользователей и прикладных программ. Иногда этот подход называют еще объектным или непроцессным.

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

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

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

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

1.      Определение функциональных задач предметной области, которые подлежат автоматизированному решению. Поскольку основной целью создания БД есть обеспечение информацией функций обработки данных, то, прежде всего, необходимо изучить все функции предметной области (объекта управления), для которой разрабатывается база данных, и проанализировать их особенности. Функции и функциональные особенности объекта управление необходимо изучать в неразрывной связи с изучением функциональных требований к данным со стороны будущих пользователей информационной системы. Изучение и анализ предусматривают выявление информационных потребностей и определения информационных потоков. Эти работы можно выполнять обследованием предметной области и анкетированием ее сотрудников. Результатом такого изучения может быть перечень функциональных задач, которые должны решаться автоматизированным способом с использованием БД.

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

3.      Изучение нормативно-справочных документов. На третьем шаге изучают и анализируют всю нормативно-справочную документацию. К такой документации принадлежат различные классификаторы, сметы, договоры, нормативы, законодательные акты по налоговой политике, плановая документация и т.п. Распределение и отдельный анализ оперативной и нормативно-справочной информации обусловлены технологически. В базы данных различаются технологии создания и ведения файлов условно-постоянной информации, размещенной в нормативно-справочной документации, и файлов оперативной информации.

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

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

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

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

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



Список литературы

1.            “Основы компьютерной бухгалтерии”. Д. В. Чистов. Москва. Издательство «Компьютер пресс». 1997 г.;

2.           “Информатика: Учебник”  Под ред. проф. Н.В. Макаровой. Москва. Издательство “Финансы и статистика”. 1998 г;

3.           “Компьютеризация бухгалтерского учета” Брага В.В. Москва. Издательство «Финстатинформ». 1996 г.

4.           “Автоматизированные информационные технологии в экономике” Банк В.Р., Зверев В.С. Астрахань. Издательство АГТУ. 2000 г.

5.           “Информатика”. В. А. Острейковский. Москва. Издательство “Высшая школа”. 1999 г.


[1] “Автоматизированные информационные технологии в экономике” Банк В.Р., Зверев В.С. Стр. 5


[2] “Информатика: Учебник”  Под ред. проф. Н.В. Макаровой. Стр. 453


[3] “Автоматизированные информационные технологии в экономике” Банк В.Р., Зверев В.С. Стр. 117