Реляционная модель данных. Основные объекты субд access

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

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

Коммерческие СУБД ведут свою историю с середины 60-х годов, когда компанией IBM был выпущен первый продукт данного класса – иерархическая СУБД IMS. В начале 70-х годов Эдгаром Коддом были заложены основы реляционной модели данных, был разработан структурированный язык запросов SQL, а в 80-х годах были созданы промышленные СУБД, которые в скором времени заняли доминирующее положение. В настоящее время ведущая тройка игроков – Microsoft, Oracle и IBM – полностью контролируют рынок, а их флагманские продукты Microsoft SQL Server, Oracle Database и IBM DB2 вместе занимают долю рынка около 90%. Рынок СУБД активно растет и, по мнению аналитиков Forrester, к 2013 году его общий объем достигнет 32 млрд долл.

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

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

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

Поскольку постреляционная модель использует многомерные структуры, позволяющие хранить в полях таблицы другие таблицы, ее еще называют "не первой нормальной формой" или "многомерной базой данных". В качестве языка в данной модели запросов используется расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения. Можно сказать, что реляционные и постреляционные СУБД различаются способами хранения и индексирования данных, во всем остальном они схожи. Первыми постреляционными СУБД, получившими достаточно большую известность, стали Universe компании Ardent (впоследствии купленной Informix, которую, в свою очередь, приобрела IBM) и ADABAS компании Software AG.

Объектно-реляционные СУБД

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

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

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

Зачастую постреляционными называют также СУБД, которые позволяют представлять данные как в виде реляционных таблиц, так и классов объектов. Типичным представителем данного вида СУБД является система Cache компании InterSystems. По словам ее разработчиков, в данной системе наиболее эффективно совмещены реляционный и объектный подходы, основанные, соответственно, на стандартах SQL-92 и ODMG 2.0. Механизмы работы с объектами и реляционными таблицами находятся на одном логическом уровне, что обеспечивает более высокую скорость доступа и работы с данными и функциональную полноту. Также Cache использует многомерную модель хранения данных и оптимизирована для обработки транзакций в системах с большими и сверхбольшими БД (сотни гигабайт, терабайты) и большим количеством (тысячи, десятки тысяч) одновременно работающих пользователей, при этом позволяя получать очень высокую производительность.

Перспективы развития

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

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

По результатам исследований компании IDC, опубликованных в конце 2009 года, традиционные реляционные СУБД используются в абсолютном большинстве крупных проектов, связанных с внедрением систем управления базами данных. Всего около 7% составляют проекты, в которых используются СУБД нереляционного типа. Такая расстановка сил на рынке реальных внедрений отражает общее состояние: разработчики все еще активно придерживаются традиционных подходов в решении задач, связанных с применением СУБД.

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

Максим Никитин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение термина Банк данных дано во Временном положении о государственном учете и регистрации баз и банков данных, утвержденное постановлением Правительства Российской Федерации от 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 Условие задачи

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

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

Прайс-лист

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

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

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

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

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

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

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

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

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

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

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


НДС, руб.;


сумма с НДС, руб..


Расчеты выполняются по следующим формулам:


S i = C i ∙Q i ,


N = ΣS i ∙ 0,18,


SN = ΣS i + N,


где S i
- стоимость i -й работы; C i
- цена за i -ю единицу продукции; Q i - обїем выполняемой i -й работы; N - НДС; SN - сумма с НДС.


2.2.3. Технология решения задачи MS Excel


Решение задачи средствами MS Excel


Вызовите Excel:


нажмите кнопку «Пуск»;


выберите в главном меню команду «Программы»;


в меню Microsoft Office выберите MS Excel.

Переименуйте «Лист 1» в «Прайс-лист»:

выберите в контекстном меню команду «Переименовать» и нажмите левую кнопку мыши;


нажмите клавишу «Enter».

Введите заголовок таблицы «Прайс-лист»:

наберите на клавиатуре «Прайс-лист»;


4. Отформатируйте заголовок:





Рис. 2. Пример выделения группы ячеек


на панели инструментов в закладке «Главная» выберите раздел «Выравнивание» и нажмите кнопку .


5. Отформатируйте ячейки А2:B2 под ввод длинных заголовков:


выделите ячейки А2:B2;


выполните команду «Выравнивание» в разделе «Формат ячеек» меню «Главная» на панели инструментов;


выберите закладку «Выравнивание»;


в группе опций «Отображение» установите флажок опции «переносить по словам» (рис. 3);





Рис. 3. Задание переноса слов при вводе в ячейку длинных


заголовков


нажмите кнопку «ОК».


6. Введите в ячейки А2:B2 информацию, представленную на рис. 4.





Рис. 4. Имена полей таблицы «Прайс-лист»


7. Отформатируйте ячейки А3:A8 для ввода текстовых символов:


выделите ячейки А3:A8;


на панели инструментов в меню «Главная» выберите «Ячейки», где в пункте «Формат» выполните команду «Формат ячеек»;


выберите закладку «Число»;


выберите формат «Текстовый» (рис. 5);


нажмите кнопку «ОК».





Рис. 5. Выбор формата ячеек


8. Повторите п. 9 для диапазона ячеек B3:B8, выбрав формат «Числовой».


9. Введите исходные данные (рис. 6).





Рис. 6. Вид таблицы «Прайс-лист»


10. Присвойте имя группе ячеек:


выделите ячейки А3:В8;


выберите команду «Присвоить имя» в разделе «Определенные имена» меню «Формулы» (рис. 7);





Рис. 7. Вид окна «Создание имени»


нажмите кнопку «ОК.».


11. Переименуйте «Лист 2» в «Расчет стоимости работ» (аналогично действиям п. 2).


12. Создайте таблицу «Расчет стоимости выполняемых работ» (аналогично действиям пунктов 3 — 7, 8) (рис. 8).





Рис. 8. Вид таблицы «Расчет стоимости работ»


13. Заполните графы «Наименование работы» и «Цена за единицу продукции, руб.»:


сделайте ячейку А3 активной;


в меню «Данные» выберите команду «Проверка данных», в поле «Тип данных» которой выберите «Список»;


введите значение в поле «Источник», выделив диапазон A3:A8 в «Прайс-лист» (рис. 9);





Рис. 9. Настройка списка плательщиков


нажмите кнопку «ОК»;


для того чтобы ввод наименования работы из списка осуществлялся в каждой ячейке столбца А («Наименование работы»), сделайте ячейку А3 активной и, установив курсор на маркер в правом нижнем углу, щелкните левой клавишей мыши и протяните его до ячейки А6 (рис. 10);





Рис. 10. Вид листа «Расчет стоимости работ» при настройке списка


в поле «Выберите функцию» нажмите «ВПР» (рис. 11);





Рис. 11. Вид первого окна мастера функций


нажмите кнопку «OK»;


введите наименование работы в поле «Искомое_значение», щелкнув по ячейке А3;


нажмите «Enter»;


введите информацию в поле «Таблица»;


воспользуйтесь командой «Использовать в формуле» меню «Формулы», выбрав «Вставить имена»;


выделите «Имя:» «Прайс_лист» (рис. 12);





Рис. 12. Ввод имени массива в качестве аргумента формулы


нажмите кнопку «OK»;


нажмите «Enter»;


введите информацию — цифру 2 в поле «Номер_столбца»;


введите информацию — цифру 0 в поле «Интервальный_просмотр» (рис. 13);





Рис. 13. Вид второго окна мастера функций


Нажмите кнопку «ОК»;


14. Заполните графу «Объем выполняемых работ».


15. Введите наименования работ в ячейки А4:А6:


Сделайте ячейку А4 активной;


Щелкните на кнопку рядом с ячейкой А4 и из предложенного списка выберите наименование работ — Замена батарей, шт. Ячейка С4 — «Цена за единицу продукции, руб.» будет заполнена автоматически (рис. 14);





Рис. 14. Автоматическое заполнение Цены за единицу продукции по ее наименованию


аналогично заполните ячейки А5:А6, ячейки С5:С6 будут также заполнены автоматически.


16. Заполнить графу «Стоимость работы, руб»
таблицы «Расчёт стоимости выполняемых работ».
Для этого:


занести в ячейку D3 формулу =B3*C3;


размножить введённую в ячейку D3 формулу для остальных ячеек D4:D6 данной графы (с помощью функции автозаполнения).


Таким образом, будет выполнен цикл, управляющим параметром которого является номер строки.


17. Заполненная таблица выглядит следующим образом (рис. 15).





Рис. 15. Результат заполнения таблицы «Расчеты стоимости работ»


18. Переименуйте «Лист 3» в « Счет» (аналогично действиям п. 2).


19. На рабочем листе «Счет» создайте необходимую таблицу, рукодствуясь предшествующими пунктами.


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


выделите диапазон ячеек А2:D6;


выберите пункт «Сортировка и фильтр» на Главной, а там «Настраиваемая сортировка»;


в выпавшем окне выберите «Сортировать по» «Наименованию работ»;


нажмите кнопку «ОК».


воспользуйтесь командой «Вставить функцию» меню «Формулы»;


в поле «Выберите функцию» нажмите «ПРОСМОТР»;


нажмите кнопку «OK»;


введите наименование работы в поле «Искомое_значение», щелкнув по ячейке С9;


нажмите «Enter»;


введите информацию в поле «Просматриваемый вектор», а именно ‘Расчет стоимости работ’!$A$3:$A$6;


нажмите «Enter»;


введите информацию в поле «Искомый вектор», а именно ‘Расчет стоимости работ’!$С$3:$С$6;


нажмите «Enter» (рис. 16);





Рис. 16. Вид второго окна мастера функции ПРОСМОТР


нажмите кнопку «ОК»;


22. Повторите действия, аналогичные п. 22 для ячеек D9:D12, E9:E12.


23. Заполнить графу «ИТОГО» таблицы следующим образом:


занести в ячейку F13 формулу =СУММ(F9:F12) .


24. Заполните графу «НДС». Для этого занести в ячейку F14 формулу =F13*0,18.


25. Заполните графу «СУММА С НДС». Для этого занести в ячейку F15 формулу =F13+F14 .


26. В результате у Вас должна получиться таблица, пркдставленная на рис. 17.





Рис. 17. Форма счета на оплату выполненных работ


27. Для анализа информации о стоимости каждого вида работ по полученному заказу:


сделайте активным лист «Счет»;


выделите диапазон C9:F12;


выберите команду «Гистограмма» в разделе «Диаграммы» меню «Вставка»;


выберите необходимый тип гистограммы;


переименуйте гистограмму в «Cтоимость каждого вида работ» (рис. 18).





Рис. 18. Гистограмма «Стоимость каждого вида работ»


2.3. Результаты компьютерного эксперимента и их анализа


2.3.1. Результаты компьютерного эксперимента


Для тестирования правильности решения задачи заполним входные документы, а затем рассчитаем результаты.


Прайс-лист
Наименование работы	Цена за единицу продукции, руб.
Замена ванны, шт.
Замена труб, м
Наклейка обоев, м2
Настилка паркета, м2
Побелка потолка, м2

Расчет стоимости выполняемых работ
Наименование работы	Объем выполняемых работ	Цена за единицу продукции, руб.	Стоимость работы, руб.
Замена батарей, шт.			1000
Замена труб, м
Наклейка обоев, м2			1400
Настилка паркета, м2			1200

	ООО «Строй-дизайн»
	СЧЕТ №
		Дата		. .20
		ФИО клиента
	№ п/п	Наименование работы	Объем выполняемых работ	Цена за единицу продукции, руб.		Стоимость работ, руб.
		Замена батарей, шт.				1000
		Наклейка обоев, м2				1400
		Замена труб, м
		Настилка паркета, м2				1200
	ИТОГО:					4560
	НДС:					820,8
	СУММА С НДС:					5380,8

В результате решения задачи полученные с помощью компьютера ведомости совпадают с тестовыми.


2.3.2. Анализ полученных результатов


Таким образом, формирование результирующего документа (таблицы) «Счет» позволяет решить поставленную задачу — сократить время на выполнения расчетов стоимости работ, исключить ошибок, обусловленных с человеческим фактором и повысить степень удовлетворенности клиента. Создание различных диаграмм (гистограмм, графиков) на основе данных таблиц средствами MS Excel позволяет не только наглядно представлять результаты обработки информации для проведения анализа с целью принятия решений, но и достаточно быстро осуществлять манипуляции в области их построения в пользу наиболее удобного представления результатов визуализации по задаваемым пользователем (аналитиком) параметрам.


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


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


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


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


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


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


В практической части была решена средства MS Excel 2010 поставленная задача в отношении условного предприятия – фирмы ООО «Строй-дизайн», которая осуществляет деятельность, связанную с выполнением работ по ремонту помещений. Были построены таблицы по приведенным данным в задании. Выполнен расчет стоимости работ по полученному заказу, данные расчета занести в таблицу. Организованы межтабличные связи с использованием функций ВПР или ПРОСМОТР для автоматического формирования счета, выставляемого клиенту для оплаты выполняемых работ. Сформирован и заполнен документ «Cчет на оплату выполненных работ». Приведены результаты расчета стоимости каждого вида работ по полученному заказу представить в графическом виде.


Компьютерная обучающая программа по дисциплине Информатика» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.Ю. Артемьев, Н.И. Лобова, К.Е. Михайлов, Г.А. Жуков, О.Е. Кричевская, С.В. Ясеновский, Л.А. Вдовенко, Б.Е. Одинцов, Г.А. Титоренко, Г.Д. Савичев, В.И. Гусев, С.Е. Смирнов, В.И. Суворова, Г.В. Федорова, Г.Б. Коняшина. – М.: ВЗФЭИ, 2000. Дата обновления 24.11.2010. – Доступ по логину и паролю.


Компьютерная обучающая программа по дисциплине «Информационные системы в экономике» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.В. Мортвичев, Б.Е. Одинцов, Г.А. Титоренко, Л.А. Вдовенко, В.В. Брага, Г.Д. Савичев, В.И. Суворова. – М.: ВЗФЭИ, 2005. Дата обновления 15.10.2010. – URL: . Доступ по логину и паролю.


СУБД ПОНЯТИЕ И ВИДЫ МОДЕЛЕЙ БАЗ ДАННЫХ СБОР ДАННЫХ СОЦИОЛОГИЧЕСКОГО ХАРАКТЕРА С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИЙ БАЗ ДАННЫХ. СОЗДАНИЕ ТАБЛИЦ И ФОРМ БД 2013-11-05

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

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

СУБД - инструментальное программное обеспечение, предназначенное для организации ведения БД.

По виду модели БД разделяются:

Иерархические БД

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

Сетевые СУБД

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

Реляционные СУБД

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

Каждый элемент таблицы - один элемент данных;

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

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

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

Объектно-ориентированные

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

Многомерные

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

9. Языки программирования. Машинный код. Трансляторы. Двоичное кодирование информации.

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

Машинный код процессора

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

Уровни языков программирования

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

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

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

Популярными на сегодня являются языки программирования:

Pascal (Паскаль), создан в конце 70-х годов основоположником множества идей современного программирования Никлаусом Виртом и имеет возможности, позволяющие успешно применять его при создании крупных проектов.

Basic (Бейсик), д ля этого языка имеются и компиляторы, и интерпретаторы, а по популярности он занимает первое место в мире. Он создавался в 60-х годах в качестве учебного языка и очень прост в изучении. Его современная модификация Visual Basic, совместимая с Microsoft office, позволяет расширять возможности пакетов Excel и Access.

С (Си), Данный язык был создан в лаборатории Bell и первоначально не рассматривался как массовый. Он планировался для замены ассемблера, чтобы иметь возможность создавать столь же эффективные и компактные программы, и в то же время не зависеть от конкретного типа процессора. На этом языке в 70-е годы написано множество прикладных и системных программ и ряд известных операционных систем (Unix).

Некоторые языки, например, Java и C#, находятся между компилируемыми и интерпретируемыми. А именно, программа компилируется не в машинный язык, а в машинно-независимый код низкого уровня, байт-код. Далее байт-код выполняется виртуальной машиной. Для выполнения байт-кода обычно используется интерпретация, хотя отдельные его части для ускорения работы программы могут быть транслированы в машинный код непосредственно во время выполнения программы по технологии компиляции «на лету» (Just-in-time compilation, JIT). Для Java байт-код исполняется виртуальной машиной Java (Java Virtual Machine, JVM), для C# - Common Language Runtime.

Постреляционные СУБД. Объектные СУБД. Недостатки реляционных СУБД. Основные концепции объектно-ориентированных СУБД.

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

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

В качестве других недостатков реляционных СУБД отмечаются следующие:

· негибкость структуры для развивающихся БД,

· затруднения в построении концептуальной модели для объектов с многочисленными связями “многие – ко – многим”,

· неестественность табличного представления для разреженных массивов данных.

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

1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-либо класса. Класс определяется как совокупность свойств, методов, общедоступных и частных структур данных, а также программы, применимых к объектам (экземплярам) данного класса. Классы представляют собой ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызываются для того, чтобы произвести какие-либо действия с объектом (например, напечатать себя или скопировать себя). Свойства - это значения данных, связанные с каждым объектом класса, характеризующие его тем или иным образом (например, цвет, возраст).

2.Инкапсуляция: Внутреннее представление данных и деталей реализации общедоступных и частных методов (программ) является частью определения класса и известно только внутри этого класса. Доступ к объектам класса разрешен только через свойства и методы этого класса или его родителей (см. ниже "наследование"), а не путем использования знания подробностей внутренней реализации.

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

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

5. Сообщения : Взаимодействие с объектами осуществляется путем посылки сообщений с возможностью получения ответов.

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

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

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

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

Объектно-реляционными СУБД являются, к примеру, Oracle Database и PostgreSQL; разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы.

Доступ к объекту в реляционных СУБД.1) СУБД определяет страницу во внешнем устройстве хранения, содержащую требуемую запись. Используя механизмы индекса или выполняя полный просмотр таблиц. Затем СУБД считывает эту страницу из внешнего устройства хранения и копирует ее в КЕШ 2.СУБД последовательно переносит данные из КЕШа в пространство памяти приложения. При этом может понадобится выполнить преобразования типов данных SQL в типы данных приложения. Приложение может обновлять значения полей в своем пространстве памяти. 3. модифицированные приложением поля данных средствами языка SQL переносится назад в КЕШ СУБД, в процессе чего может опять потребоваться выполнить преобразование типов данных. 4. СУБД сохраняет обновленную страницу на внешнем устройстве хранения переписывая ее из КЕШа.

Доступ к объекту в ООСУБД. 1. ООСУБД наход ит на внешнем уст-ве хранения страницу, содержащую требуемый объект, используя его индекс если это необходимо. Затем ООСУБД считывает из внешнего устр-ва хранения требуемую страницу и копирует ее в КЕШ страниц приложения, находящийся в пределах памяти, отведенной приложению. 2. ООСУБД м ожет выполнить несколько преобразований: 1. подстановку ссылок (указателей) одного объекта на другой. 2. введение в состав данных объекта информации, которая необходима для обеспечения соответствия требованиям, предъявляемым со стороны языка программирования. 3. Изменение формата представления данных созданных на разных аппаратных платформах или языках программирования. 3. Приложение осуществляет доступ к объекту и обновляет его по мере необходимости. 4. Когда приложению потребуется сделать внесенные изменения пермонентными или выгрузить на время стр. из КЕШа на диск, то перед копированием стр. на внешнее уст-во хранения ООСУБД должна выполнить обратные преобразования аналогичные описанным выше.

Билет №27

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

Деловая активность предприятия обычно характеризуется интен­сивностью использования инвестированного (внутреннего) капитала. В производстве капитал находится в постоянном движении, переходя из одной стадии кругооборота в другую: т. е. реализуется технология Д®Т®…®П®…Т®Д". Деньги, товар

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

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

План-конспект урока

Тема: Базы данных. Основные объекты БД. СУБД.

Цель урока:

• 1. Познавательная - познакомить учащихся с:
  • определением базы данных и СУБД,
  • их основными типами (моделями),
  • интерфейсом программы Ms ACCESS,
  • основными объектами БД,
  • разными способами создания таблиц.
• 2. Развивающая
  • Учить строить аналогии, выделять главное, ставить и решать проблемы.
• 3. Воспитательная
  • Воспитывать аккуратность, внимательность, вежливость и дисциплинированность.

План урока:

• 1. Актуализация опорных знаний.
• 2. Запуск программ на выполнение;
• 3. Ввод данных в таблицу.

1 Определение БД И СУБД

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

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

БД делятся на фактографические и документальные. Фактографические БД содержат короткие сведения об объектах, поданные в точно определенном формате (1-3), например, Автор, название, год издания … В документальных БД содержится информация разного типа: текстовая, звуковая, графическая, мультимедийная (4, 5). Например, БД современной музыки может содержать тексты и ноты песен, фотографии авторов, звуковые записи, видеоклипы. Сама по себе БД содержит только информацию – «Информационный склад» –и не может обслуживать запросы пользователя на поиск и обработку информации. Обслуживание пользователя осуществляет СИСТЕМА УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ. СУБД – Это ПО, которое позволяет создавать БД, обновлять и дополнять информацию, обеспечивать гибкий доступ к информации. СУБД создает на экране компьютера определенную среду для работы пользователя (интерфейс), и имеет определенные режимы работы и систему команд. Именно на основе СУБД создаются и функционируют информационно-поисковые системы(WWW).

3. Типы СУБД

Известны 3 способа организации информации в БД и связей между ними:

• Иерархические (в виде дерева),
• Сетевые,
• Реляционные.

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

4. Реляционная СУБД. Таблица, запись, поле.

Реляционной (от английского “ relation” - отношение) называется БД, которая содержит информацию, организованную в виде прямоугольной таблицы. Каждая строка таблицы содержит информацию об одном конкретном объекте БД (книге, сотруднике, товаре), а каждый столбец – конкретную характеристику этого объекта (фамилия, название, цена). Строки такой таблицы называются записями, столбцы – полями. Каждая запись должна отличаться от другой значением хотя бы одного поля, которое называется ключом. Ключевое поле – это поле или группа полей, которые однозначно определяют запись. Например, табельный номер сотрудника, код изделия, номер автомобиля. Таб_№ ФИО Дата_рожд Дата_приема Должность Оклад 001 < Иванов И.И. 12.05.65 1.02.80 директор 1000 002 Петров П.П. 30.10.75 2.03.95 бугалтер 500 003 Сидоров С.С 4.01.81 4.06.00 исполнитель 100 Каждое поле имеет свой формат и тип. Реальные БД состоят, как правило, из нескольких таблиц, связанных между собой каким-нибудь полем и, при запросе к такой БД можно использовать информацию из разных таблиц. Основные объекты БД:

• Таблицы - основные объекты БД, где хранится информация,
• Запросы – предназначенные для выбора нужных данных из одной или нескольких взаимосвязанных таблиц.
• Формы – предназначенные для ввода, просмотра и редактирования взаимосвязанных данных в удобном виде.
• Отчёты – формирование данных в удобном для просмотра виде и при необходимости их печати.

5. Самостоятельная работа на компьютере

На сетевом диске, в папке «ЗАДАНИЯ ДЛЯ БД» открыть презентацию «Базы данных и СУБД», прочитать ее и ответить письменно на вопросы:

• 1. Какое основное назначение БД?
• 2. По каким критериям классифицируются БД? Укажите критерий и виды, соответственно этого критерия.
• 3. Что такое ключевое поле в БД?
• 4. Какой основной элемент БД?
• 5. Какие операции можно производить с помощью СУБД с БД?
• 6. Основные типы данных в таблицах СУБД.

6. Итоги урока

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

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

Создание базы данных. Ввод и форматирование данных

• 1. Включите компьютер. Загрузите СУБД ACCESS. Сначала нужно создать новую базу данных.
• 2. Выполним следующую последовательность действий: в меню Файл выберем команду Создать. Имя файла: skaz.mdb. OK. Перед вами появилось диалоговое окно «База данных».
• 3. Внимательно прочитайте назначение кнопок на панели инструментов, медленно перемещая курсор мыши по кнопкам.
• 4. После этого создайте таблицу, выполнив следующую последовательность действий: Таблица/Создать/Новая таблица.

Создание таблицы, то есть определение входящих в таблицу полей, производится заполнением специальной таблицы: Поле Тип данных Описание

• 5. Заполните такую таблицу, внеся в нее следующие данные:

Поле Тип данных Описание № Счетчик Персонаж Текстовый Профессия Текстовый Особые приметы Текстовый Герой Логический Положительный или отрицательный герой

• 6. Поле № не обязательное, мы его вводим для того, чтобы определить ключевое поле, так как любая таблица должна иметь ключ.
• 7. Созданную таблицу нужно сохранить, дав ей имя с помощью команд: Файл/Сохранить как..., Имя таблицы: «Персонаж», OK.
• 8. Введите информацию в таблицу Таблица/«Персонаж»/Открыть и обычным образом введите данные, например такие:

№ Персонаж Профессия особые приметы герой

• 1 Буратино деревянный человечек длинный нос Да
• 2 Папа Карло Шарманщик Да
• 3 Карабас Барабас директор кукольного театра длинная борода, достающая до пола Нет
• 4 Лиса Алиса Мошенница хромая на одну ногу Нет
• 5 Кот Базилио Мошенник слепой на оба глаза Нет
• 6 Мальвина артистка театра девочка с голубыми волосами Да
• 7 Дуремар Фармацевт характерный запах тины Нет
• 8 Тортилла хранительница золотого ключика черепаха Да
• 9. При помощи мыши выделите:
  • а) запись 5,
  • б) запись 3,
  • в) с третьей по седьмую запись. Отмените выделение.
  • г) Выделите все записи. Отмените выделение.
  • д) Выделите поле «Персонаж».
  • е) Выделите одновременно поля: «Профессия», «Особые приметы» и «Герой», отмените выделение.
  • ж) Выделите все поля. Это можно сделать при помощи мыши или в меню Правка выбрать команду Выделить все записи.
• 10. Отмените выделение.
• 11. Выделите:
  • а) В поле «Особые приметы» отметьте шестую запись.
  • б) В поле «Персонаж» выделите с четвертой по шестую запись.
  • в) Не отпуская кнопку мыши, отметьте эти же записи в полях «Особые приметы» и «Герой».
• 12. Отмените выделение.
• 13. Выделите всю таблицу.
• 14. Отмените выделение.
• 15. Измените ширину каждого столбца, так чтобы ширина колонок была минимальной, но был виден весь текст.

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

• 16. Любым способом измените высоту строки и сделайте ее равной 30.
• 17. Измените шрифт таблицы на Arial Cyr, размер шрифта 14, полужирный.

Изменить шрифт можно так: вывести указатель мыши за пределы таблицы и нажать левую кнопку мыши, в контекстном меню выбрать Шрифт или в меню Правка на панели инструментов выбором команды Шрифт.

• 18. Измените шрифт текста на Times New Roman Cyr, размер шрифта 10.
• 19. Измените ширину полей.
  • а) Сделайте столбец «Персонаж» шириной 20.
  • б) Столбец «Особые приметы» шириной 25.

Вы видите, что текст в этих полях напечатался в две строки.

• 20. Подгоните ширину столбцов так, чтобы текст вмещался полностью.
• 21. Выполните сортировку таблицы по полю «Персонаж» в порядке, обратном алфавитному.

Это можно сделать так. Выделите поле «Персонаж» и нажмите кнопку Сортировка по убыванию на панели инструментов.

• 22. Верните таблицу в исходное состояние.