Понятие реляционных данных и СУБД

<

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

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

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

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

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

Централизованное управление данными имеет преимущества по сравнению с обычной файловой системой:

— сокращение избыточности хранения данных;

— сокращение трудоемкости разработки, эксплуатации и модернизации ИС;

-обеспечение удобного доступа к данным как пользователям

— профессионалам в области обработки данных, так и конечным пользователям.

Основные требования, предъявляемые к БнД:

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

— возможность взаимодействия пользователей разных категорий, высокая эффективность доступа к данным;

— дружелюбность интерфейсов, малое время на обучение;

— обеспечение секретности и разграничение доступа к данным для разных пользователей;

— надежность хранения и защита данных.

Определение термина Банк данных дано во Временном положении о государственном учете и регистрации баз и банков данных, утвержденное постановлением Правительства Российской Федерации от 28.02.96 № 226, п.2 (СЗ РФ, 1996, № 12, ст. 1114)

Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства — MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

В 1963 году С. Бахманом была построена первая промышленная база данных IDS с сетевой моделью данных, которая все еще характеризовалась избыточностью данных и их использованием только для одного приложения. Доступ к данным осуществлялся с помощью соответствующего программного обеспечения. В 1969 году сформировалась группа, создавшая набор стандартов CODASYL для сетевой модели данных.

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

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

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

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

СУБД организует хранение информации таким образом, чтобы ее было удобно:

просматривать,

пополнять,

изменять,

искать нужные сведения,

делать любые выборки,

осуществлять сортировку в любом порядке.

Классификация баз данных:

а) по характеру хранимой информации:

— фактографические (картотеки),

— документальные (архивы)

б) по способу хранения данных:

— централизованные (хранятся на одном компьютере),

— распределенные (используются в локальных и глобальных компьютерных сетях).

в) по структуре организации данных:

— табличные (реляционные),

— иерархические,

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

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

Популярные СУБД — FoxPro, Access for Windows, Paradox. Для менее сложных применений вместо СУБД используются информационно-поисковые системы (ИПС), которые выполняют следующие функции:

хранение большого объема информации;

быстрый поиск требуемой информации;

добавление, удаление и изменение хранимой информации;

вывод ее в удобном для человека виде.

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

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

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

В настоящее время наблюдается стремительный рост числа систем электронной коммерции (СЭК). Электронная коммерция имеет ряд отличительных особенностей, резко выделяющих её от всех ранее известных способов классической коммерции благодаря исключительным коммуникативным характеристикам Интернета

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

СЭК обладает набором специфических свойств, которые отличают их от классических систем коммерции (обыкновенные магазины, супермаркеты, биржи и т.п.). В то же время эти свойства необходимо учитывать при построении и анализе моделей процессов в СЭК, поскольку классическая постановка оптимизационной задачи оптимального управления дискретной системой не подходит. Итак, свойства СЭК: Время работы неограниченно в отличие от классических систем, где есть строго регламентированное расписание работы. Можно говорить о том, что поток посетителей распределен равномерно во времени. В отличие от классических систем в СЭК (особенно это характерно для систем класса B2C) посетители приходят не только за покупками, но и за получением некоторой информации: ознакомиться с ассортиментом, ценами, условиями оплаты и доставки товара.

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

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

СЭК может обслуживать одновременно достаточно большое число посетителей. Эта характеристика ограничена только программно-аппаратными возможностями СЭК. То есть в случае СЭК с точки зрения пользователя нет очередей ожидания обслуживания. Особенно это характерно для полностью или частично автоматизированных СЭК.

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

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

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

 

1.2 Реляционные базы данных

 

Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) — СУБД, управляющая реляционными базами данных.

Понятие реляционный (англ. relation — отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

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

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

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

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

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

Базовыми понятиями реляционных СУБД являются: 1) атрибут; 2) отношения; 3) кортеж.

База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

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

Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).

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

Несмотря на рассмотренные недостатки реляционных баз данных, они обладают рядом достоинств:

разделение таблиц разными программами;

развернутый «код возврата» при ошибках;

высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);

сама концепция объектных баз данных довольно сложна и требует от программистов серьезного и длительного обучения;

относительно высокая скорость при работе с большими объемами данных.

Кроме того, во всем мире значительные средства уже инвестированы в реляционные СУБД. Многие организации не уверены, что затраты, связанные с переходом на объектные базы данных, окупятся.

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

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

Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут сами выполнять роль мощного объектно-реляционного адаптера, позволяя объектно-ориентированным приложениям обращаться к реляционным БД.

Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД.

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

Производительность в рассмотренных двух подходах зависит от способа доступа к реляционной базе данных. Каждая РСУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Производительность в первом случае намного ниже (например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне).

Гибридные СУБД – еще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают (или планируют) добавлять к своим продуктам объектно-ориентированные средства. В частности, Sybase и Informix собираются в следующих версиях СУБД ввести поддержку объектов. Подобные разработки намерены вести и независимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствами СУБД Oracle8, выпуск которой намечен на конец 1996 г.

С другой стороны, производители объектных СУБД, такие как компания Object Design, сознают, что объектно-ориентированные базы данных в обозримом будущем не заменят реляционные СУБД. Это вынуждает их создавать шлюзы для поддержки реляционных и иерархических баз данных иди различного рода интерфейсы, характерным примером которых является объектно-реляционный интерфейс Ontos Integration Server фирмы Ontos, применяемый в сочетании с ее ООБД Ontos/DB.

 

1.3 Многомерные базы данных

 

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

В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

Поликубов – каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы.

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства:

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

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

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

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

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

Еще к недостаткам MOLAP-моделей можно отнести:

не позволяют работать с большими БД. На сегодняшний день их реальный предел – 10-20 гигабайт. К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, как правило, соответствуют (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных, то есть в лучшем случае нескольким гигабайтам.

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

отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными

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

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

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

время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

 

 

 

 

 

 

 

 

 

 

 

2. Практическая часть


 

2.1 Постановка задачи


 

2.1.1 Цель решения задачи

 

Руководство предприятия ООО «Строй-дизайн», осуществляющего деятельность, связанную с выполнением работ по ремонту помещений, желает произвести автоматизацию расчетов по вычислению стоимоти выполняемых работ для оперативного предоставления счета клиенту. Это поможет сократить время расчетов, избежать ошибок, связанных с человеческим фактором и повысить степень удовлетворенности клиента оказанными услугами. Поэтому принято решение вести расчет стоимости выполненных работ и создание счета на их оплату, в которых должны быть наименование работ, объем выполняемых работ, цена за единицу продукции, стоимость работы. Задача, которая будет решаться в программной среде MS Excel ежемесячно, называется «Расчет стоимости выполненных работ».

Цель решения данной задачи состоит в своевременности расчетов стоимости работ для оперативного предоставления подробно составленного счета клиентам.

 

2.1.2 Условие задачи

 

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

 

Расчет стоимости выполняемых работ 

Наименование
работы

Единицы
измерения

Объем
выполняемых
работ

Цена за единицу продукции, руб.

Стоимость
работ, руб.

   

Qi

Cі

Si

 


Условно-постоянной информацией (справочной) служит прайс-лист организации, содержащий следующие реквизиты (условная форма): наименование работы, цена за единицу продукции (руб). На его основании создается следующая экранная форма:

Прайс-лист

Наименование работы 

Цена за единицу продукции, руб. 

   

 

Латинские буквы в таблице указывают на элементы соответствующих расчетных формул.

В результате следует получить счет со следующими реквизитами: наименование работы, цена за единицу продукции (руб.), объем выполняемых работ, стоимость работы (руб.), № счета (заполняется автоматически). ФИО клиента и дата вписываются вручную. Информация выдается в следующих документах:


 

 

 

 

 

 

 

 

 

 

Структура результирующего документа «Счет»


 

ООО «Стройсервис» 


 


 

СЧЕТ №


 


 

   

Дата 

__.__.20__ 

   


 


 

 

ФИО клиента


 

 


 

<


 

           


 


 


п/п

Наименование
работы

Единицы
измерения

Объем
выполняемых
работ

Цена за единицу продукции, руб.

Стоимость
работ, руб.


 


 

1 

Замена батарей

шт. 

     


 


 

2 

Наклейка обоев

м2

     


 


 

3 

Замена труб 

м 

     


 


 

4 

Настилка паркета

м2

     


 


 

ИТОГО: 

ΣSi

 


 

НДС: 

N


 


 

СУММА С НДС: 

SN 


 


 

           


 


 

 

Гл. бухгалтер 


 


 

   


 

 

Кроме того, информацию, находящуюся в таблицах для анализа, необходимо представить в виде диаграмм.

В технологии организовать межтабличные связи для автоматического формирования документа «Счет» при помощи функций ВПР или ПРОСМОТР.

 

2.2. Компьютерная модель решения задачи


 

2.2.1. Информационная модель решения задачи

 

110513 0111 2 Понятие реляционных данных и СУБДИнформационная модель, отражающая взаимосвязь исходных и результирующих документов, приведена на рис. 2.

110513 0111 3 Понятие реляционных данных и СУБД


 

2.2.2. Аналитическая модель решения задачи

 

Для получения документа «Расчет стоимости выполняемых
работ» необходимо рассчитать следующие показатели:

  1. Переименуйте «Лист 1» в «Прайс-лист»:
  • установите курсор мыши на ярлык «Лист 1» (нижняя часть экрана) и нажмите правую кнопку мыши;
  • выберите в контекстном меню команду «Переименовать» и нажмите левую кнопку мыши;
  • наберите на клавиатуре «Прайс-лист»;
  • нажмите клавишу «Enter».
  1. Введите заголовок таблицы «Прайс-лист»:
  1. Агальцов В.П., Титов В.М. Информатика для экономистов: учебник. – М.: Форум : ИНФРА-М, 2006.
  2. Алексеев А.П. Информатика 2010.–М.: СОЛОН-Р, 2010.
  3. Информатика в экономике: учебное пособие / под ред. Б.Е. Одинцова, А.Н. Романова. – М.: Вузовский учебник, 2008.
  4. Информатика: Базовый курс: учебное пособие / под ред. С.В. Симоновича. – СПб.: Питер, 2009.
  5. Информатика для экономистов: учебник / под ред. В.М. Матюшка. – М.: ИНФРА-М, 2006.
  6. Информатика. Общий курс: учебник / А.Н. Гуда, М.А. Бутакова, Н.М. Нечитайло, А.В. Чернов; под общ.ред. В.И. Колесникова. – М.: ИТК «Дашков и Ко», 2009.
  7. Информатика: практикум для экономистов: учебное пособие / под ред. В.П. Косарева. – М.: Финансы и статистика : ИНФРА-М, 2009.
  8. Информатика: методические указания по выполнению курсовой работы для студентов второго курса всех специальностей. – М.: ВЗФЭИ, 2008. – URL: http://repository.vzfei.ru. Доступ по логину и паролю.
  9. Информатика. Лабораторный практикум для студентов 2 курса всех специальностей и направлений / В.Н. Дулькин, О.Е. Кричевская, А.В. Парфенова. – М.: Вузовский учебник, 2006. – URL: http:// repository.vzfei.ru. Доступ по логину и паролю.
  10. Информатика / Под ред. Н.В. Макаровой.–М.: Финансы и статистика, 2004.
  11. Практикум по экономической информатике: учебное пособие. Ч. II / под ред. В.П. Косарева, Г.А. Титоренко, Е.А. Мамонтовой. – М.: Финансы и статистика : Перспектива, 2002.
  12. Практикум по экономической информатике: учебное пособие. Ч. III / под ред. П.П. Мельникова. – М.: Финансы и статистика : Экономическая информатика: учебник для вузов / под ред. В.П. Косарева. – М.: Финансы и статистика, 2006.
  13. Компьютерная обучающая программа по дисциплине Информатика» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.Ю. Артемьев, Н.И. Лобова, К.Е. Михайлов, Г.А. Жуков, О.Е. Кричевская, С.В. Ясеновский, Л.А. Вдовенко, Б.Е. Одинцов, Г.А. Титоренко, Г.Д. Савичев, В.И. Гусев, С.Е. Смирнов, В.И. Суворова, Г.В. Федорова, Г.Б. Коняшина. – М.: ВЗФЭИ, 2000. Дата обновления 24.11.2010. – http://bukvi.ru/Доступ по логину и паролю.
  14. Компьютерная обучающая программа по дисциплине «Информационные системы в экономике» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.В. Мортвичев, Б.Е. Одинцов, Г.А. Титоренко, Л.А. Вдовенко, В.В. Брага, Г.Д. Савичев, В.И. Суворова. – М.: ВЗФЭИ, 2005. Дата обновления 15.10.2010. – URL: http://bukvi.ru/. Доступ по логину и паролю.
  15. Федеральная ЭБС «Единое окно доступа к образовательным ресурсам». – URL: http://window.edu.ru. Доступ свободный.
  16. Фигурнов В.Э. IBM PC для пользователя — Уфа: НПО «Информатика и компьютеры», 2006.
  17. Электронные каталоги АИБС МАРК-SQL: «Книги», «Статьи», «Диссертации», «Учебно-методическая литература», «Авторефераты», «Депозитарный фонд». – URL: http://http://bukvi.ru//rus/library/elect_lib.htm. Доступ свободный.


     

<

Комментирование закрыто.

MAXCACHE: 1.07MB/0.00048 sec

WordPress: 23.74MB | MySQL:117 | 3,173sec