Часть реального мира подлежащая автоматизации

Часть реального мира подлежащая автоматизации

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

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

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

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

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

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

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

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

Обычно современная СУБД содержит следующие компоненты (см. рис.):

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

Часть реального мира подлежащая автоматизации

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

• применение вычислительной техники для выполнения численных расчетов;
• использование средств вычислительной техники в информационных системах.

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

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

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

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

Существуют 4 основные модели данных – списки (плоские таблицы), реляционные базы данных, иерархические и сетевые структуры.

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

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

Основные понятия реляционных БД: нормализация, связи и ключи

1. Принципы нормализации:

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

2. Виды логической связи.

Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».

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

• один – к — одному, каждой записи из одной таблицы соответствует одна запись в другой таблице;
• один – ко — многим, каждой записи из одной таблицы соответствует несколько записей другой таблице;
• многие – к — одному, множеству записей из одной таблице соответствует одна запись в другой таблице;
• многие – ко — многим, множеству записей из одной таблицы соответствует несколько записей в другой таблице.

Тип отношения в создаваемой связи зависит от способа определения связываемых полей:

1. Отношение «один-ко-многим» создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса.
2. Отношение «один-к-одному» создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.
3. Отношение «многие-ко-многим» фактически является двумя отношениями «один-ко-многим» с третьей таблицей, первичный ключ которой состоит из полей внешнего ключа двух других таблиц

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

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

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

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

Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.

Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение.

Простой ключ. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null.

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

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

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

Программы, которые предназначены для структурирования информации, размещения ее в таблицах и манипулирования данными называются системами управления базами данных ( СУБД). Другими словами СУБД предназначены как для создания и ведения базы данных, так и для доступа к данным. В настоящее время насчитывается более 50 типов СУБД для персональных компьютеров. К наиболее распространенным типам СУБД относятся: MS SQL Server, Oracle, Informix, Sybase, MS Access и т. д.

Создание БД. Этапы проектирования

Создание БД начинается с проектирования.

Этапы проектирования БД:

• исследование предметной области;
• анализ данных (сущностей и их атрибутов);
• определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.

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

К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).

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

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

Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц).

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

Рассмотрим предметную область: Деканат (Успеваемость студентов).

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

Основными предметно-значимыми сущностями БД «Деканат» являются: Студенты, Группы студентов, Дисциплины, Успеваемость.

Основные предметно-значимые атрибуты сущностей:

• студенты – фамилия, имя, отчество, пол, дата и место рождения, группа студентов;
• группы студентов – название, курс, семестр;
• дисциплины – название, количество часов;
• успеваемость – оценка, вид контроля.

Основные требования к функциям БД:

• выбрать успеваемость студента по дисциплинам с указанием общего количества часов и вида контроля;
• выбрать успеваемость студентов по группам и дисциплинам;
• выбрать дисциплины, изучаемые группой студентов на определенном курсе или определенном семестре.

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

Логическая связь между сущностями Группы – Студенты определена как один – ко – многим исходя из того, что в группе имеется много студентов, а каждый студент входит в состав одной группе. Логическая связь между сущностями Дисциплины – Успеваемость определена как один – ко – многим, потому что по каждой дисциплине может быть поставлено несколько оценок различным студентам.

На основе вышеизложенного составляем модель сущность – связь для БД «Деканат»

— стрелка является условным обозначением связи: один – ко – многим.

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

КОНСПЕКТ ЛЕКЦИЙ «ОСНОВЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ» для специальностей 09.02.04 «Информационные системы (по отраслям)» 09.02.05 «Прикладная информатика (по отраслям)»
учебно-методическое пособие на тему

Конспект лекций содержит теоретический материал в ком­пактной форме и представляет собой тезисы лекции, расположенные в соответствии с планом лекции. Предназначен для студентов специальностей среднего профессионального образования 09.02.04 «Информационные системы (по отраслям)», 09.02.05 «Прикладная информатика (по отраслям)».

Скачать:

Вложение	Размер
konspekt_lektsiy_opbd_2015.doc	622 КБ

Предварительный просмотр:

Главное управление образования Курганской области

Государственное бюджетное профессиональное образовательное учреждение

«Курганский технологический колледж

имени Героя Советского Союза Н.Я. Анфиногенова»

«ОСНОВЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ»

09.02.04 «Информационные системы (по отраслям)»

09.02.05 «Прикладная информатика (по отраслям)»

Медведева А.А. Конспект лекций «Основы проектирования баз данных» / А.А. Медведева. – Курган, 2015. – 64 с.

Рассмотрено на заседании ЦМК ИиТД

Протокол от___ №________________

Автор-составитель: Медведева А.А. – преподаватель ГБПОУ «КТК»

Конспект лекций содержит теоретический материал в компактной форме и представляет собой тезисы лекции, расположенные в соответствии с планом лекции. Предназначен для студентов специальностей среднего профессионального образования 09.02.04 «Информационные системы (по отраслям)», 09.02.05 «Прикладная информатика (по отраслям)».

© Медведева А.А., 2015

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

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

Лекция 1. Основные понятия теории баз данных

1. Основные понятия теории баз данных
2. История возникновения баз данных
3. История развития баз данных
4. Классификация БД

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

Информационные системы имеют следующие особенности:

• для обеспечения их работы нужны сравнительно низкие вычислительные мощности
• данные, которые они используют, имеют сложную структуру
• необходимы средства сохранения данных между последовательными запусками системы, …

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

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

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

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

Основные функции СУБД:

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

История возникновения БД

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

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

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

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

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

Обычно такие системы имеют дело с большими объемами информации, имеющей достаточно сложную структуру.

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

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

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

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

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

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

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

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

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

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

История развития БД

Концепция БД сложилась в конце 60-х годов прошлого столетия и с тех пор постоянно развивалась.

Первый этап сложился к началу 60-х годов прошлого века и характеризуется следующими признаками:

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

Второй этап относится к середине 60-х годов и имеет следующие особенности:

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

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

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

Четвертый этап датируется второй половиной 70-х годов. На этом этапе были реализованы следующие основные характеристики СУБД:

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

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

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

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

Классификация БД может быть произведена по различным признакам, среди которых выделяют:

1. По форме представления информации: фактографические и документальные.
2. По типу используемой модели данных: иерархические, сетевые, реляционные.
3. По типологии хранения данных: локальные (централизованные) и распределённые (удалённые) БД.

Классификация не является полной. Различные источники предоставляют разнообразную классификацию.

Вопросы для самоконтроля:

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

Лекция 2-3. Технологии работы с базами данных

1. Централизованная архитектура
2. Архитектура «файл-сервер»
3. Технология «клиент – сервер»
4. Трехзвенная (многозвенная) архитектура «клиент – сервер»

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

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

Рисунок 1 — Централизованная архитектура

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

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

Рисунок 2 — Архитектура «файл-сервер»

Технология «клиент – сервер»

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

Так, архитектура » клиент – сервер » разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Language), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД.

SQL-сервер – специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети «путешествуют» только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами.

Архитектура системы представлена на рисунке 3 .

Рисунок 3 — Архитектура «клиент – сервер»

Трехзвенная (многозвенная) архитектура «клиент – сервер»

Трехзвенная (в некоторых случаях многозвенная ) архитектура (N-tier или multi-tier). представляет собой дальнейшее совершенствование технологии » клиент – сервер «. Рассмотрев архитектуру » клиент – сервер «, можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс.

Схематически такую архитектуру можно представить, как показано на рисунке 4.

Рисунок 4 — Представление многоуровневой архитектуры «клиент-сервер»

Вопросы для самоконтроля:

1. Назовите достоинства и недостатки существующих многопользовательских технологий с базами данных.

Лекция 4. Логическая и физическая независимость данных

1. Базовые понятия
2. Архитектура базы данных
3. Механизм прохождения запроса к БД

Современные авторы часто употребляют термины «банк данных» и «база данных» как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:

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

База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.

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

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

Архитектура базы данных

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

Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рисунке 5.

Рисунок 5 — Трехуровневая модель системы управления базой данных, предложенная ANSI

Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению.

Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными.

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

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

Процесс прохождения пользовательского запроса

Рисунок 6 иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке запроса на получение данных. Цифрами помечена последовательность взаимодействий:

Рисунок 6 — Схема прохождения запроса к БД

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

Вопросы для самоконтроля:

1. Каким образом прикладные программы взаимодействуют с БД?
2. Чем банк данных отличается от базы данных?
3. Какие компоненты входят в состав банка данных?
4. Что представляет собой трехуровневая архитектура СУБД?
5. В чем особенность уровня внешних моделей?
6. В чем особенность концептуального уровня?
7. В чем особенность физического уровня?
8. Что означает логическая и физическая независимость данных?

Лекция 5. Типы моделей данных. Реляционная модель данных

1. Иерархическая модель базы данных
2. Сетевая модель базы данных
3. Реляционная модель базы данных

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

Иерархическая модель базы данных

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

Каждая запись может иметь не более одной родительской записи и несколько подчиненных.

Связи записей реализуются в виде физических указателей с одной записи на другую.

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

Иерархические базы данных графически могут быть представлены как перевернутое дерево, состоящее из объектов различных уровней. Верхний уровень (корень дерева) занимает один объект, второй — объекты второго уровня и так далее.

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

• Атрибут (элемент данных) — наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.
• Запись — именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи — конкретная запись с конкретным значением элементов.
• Групповое отношение — иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) — подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.

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

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

Операции над данными, определенные в иерархической модели:

• Добавить в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.
• Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.
• Удалить некоторую запись и все подчиненные ей записи.
• Извлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей.
• Извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева).

В операции ИЗВЛЕЧЬ допускается задание условий выборки.

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

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

Сетевая модель базы данных

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

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

Операции над данными в сетевой модели БД

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

В сетевой модели обеспечивается только поддержание целостности по ссылкам (владелец отношения — член отношения).

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

Реляционная модель была предложена в 1969 году сотрудником фирмы IBM Е. Ф. Коддом (Or. Е. Р. Соdd), известным исследователем в области баз данных. Впервые основные концепции этой модели были опубликованы в 1970 году.

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

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

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

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

Данные в реляционной таблице должны удовлетворять следующим принципам:

1. Каждое значение поля должно быть атомарным, т.е. не расчленяемым на несколько значений;

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

3. Каждая запись в таблице уникальна, т.е. в таблице не существует двух записей с полностью совпадающим набором значений ее полей;

4. Каждое поле имеет уникальное имя;

5. Последовательность полей в таблице несущественна;

6. Последовательность записей в таблице несущественна.

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

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

Первичный ключ — это поле или набор полей, которые однозначно идентифицируют (определяют) запись таблицы

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

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

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

Типичная реляционная база данных состоит из нескольких связанных таблиц.

Типы связей между объектами

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

1. Отношение «один – ко – многим» (обозначают 1:М): одной записи из главной таблицы может соответствовать ноль, одна или несколько записей подчинённой таблицы.

2. Отношение «один – к — одному» (обозначают 1:1): одной записи из главной таблицы соответствует только одна запись из подчинённой таблицы.

3. Отношение «многие – ко – многим» (обозначают 1:1): одной записи из главной таблицы может соответствовать ноль, одна или несколько записей подчинённой таблицы и наоборот.

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

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

Вопросы для самоконтроля:

1. Что такое модель данных?
2. Для чего строится модель данных?
3. Укажите достоинства и недостатки иерархической модели данных.
4. Как организуется физическое размещение данных в БД иерархического типа?
5. Охарактеризуйте сетевую модель данных.
6. Охарактеризуйте реляционную модель данных.
7. Чем отличается реляционная модель данных от предшествующих ей моделей?
8. Что такое простой ключ и составной ключ?
9. Перечислите виды связей между объектами? Охарактеризуйте их.
10. Как проявляется иерархическая подчиненность в связи «один ко многим»?

Лекция 6. Реляционная алгебра

1. Традиционные операции реляционной алгебры
2. Специальные операции реляционной алгебры

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

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

Реляционная алгебра в том виде, в котором она была определена Э. Ф. Коддом, состоит из двух групп по четыре оператора.

1. Традиционные операции: объединение, пересечение, разность и декартово произведение.

2. Специальные реляционные операции: выборка, проекция, соединение, деление.

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

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

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

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

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

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

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

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

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

Вопросы для самоконтроля:

1. Сколько реляционных операций образуют реляционную алгебру?
2. Перечислите и охарактеризуйте операции реляционной алгебры. Приведите примеры.

Лекция 7. Основные этапы проектирования БД

1. Жизненный цикл БД
2. Планирование разработки базы данных
3. Определение требований к системе
4. Сбор и анализ требований пользователей
5. Проектирование базы данных
6. Разработка приложений
7. Реализация
8. Загрузка данных
9. Тестирование
10. Эксплуатация и сопровождение

Жизненный цикл БД

Как и любой программный продукт, база данных обладает

собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ,

необходимых для ее работы.

ЖЦБД включает в себя следующие основные этапы (рисунок 7):

Рисунок 7 — Жизненный цикл БД

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

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

Планирование разработки базы данных состоит в определении трех основных компонентов: объема работ, ресурсов и стоимости проекта.

Важной частью разработки стратегического плана является проверка

осуществимости проекта, состоящая из нескольких частей.

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

Вторая часть — проверка операционной осуществимости — выяснение наличия экспертов и персонала, необходимых для работы БД.

Третья часть — проверка экономической целесообразности осуществления проекта. При исследовании этой проблемы весьма важно дать оценку ряду факторов, в том числе и таким:

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

Определение требований к системе

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

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

Сбор и анализ требований пользователей

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

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

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

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

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

Концептуальное проектирование базы данных

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

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

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

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

Логическое проектирование базы данных

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

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

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

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

Физическое проектирование базы данных

Целью проектирования на данном этапе является создание описания СУБД ориентированной модели БД.

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

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

Параллельно с проектированием системы базы данных выполняется разработка приложений. Главные составляющие данного процесса — это проектирование транзакций и пользовательского интерфейса.

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

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

Проектирование транзакций заключается в определении:

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

Проектирование пользовательского интерфейса

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

Специалисты рекомендуют при проектировании пользовательского интерфейса использовать следующие основные элементы и их характеристики:

• содержательное название;
• ясные и понятные инструкции;

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

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

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

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

Реализация этого, а также и более ранних этапов проектирования БД может осуществляться с помощью инструментов автоматизированного проектирования и создания программ, которые принято называть CASE-инструментами (Computer-Aided Software Engineering).

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

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

• нисходящее тестирование;
• восходящее тестирование;
• тестирование потоков;
• интенсивное тестирование.

Эксплуатация и сопровождение

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

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

Вопросы для самоконтроля:

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

Лекция 8. Концептуальное проектирование БД

1. Модель «Сущность — Связь»(ERD)
2. Структурный подход при разработке инфологической модели
3. Моделирование локальных представлений
4. Правила преобразования ER-диаграмм в реляционные таблицы

Концептуальная модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них оказалась модель «сущность-связь».

Модель «Сущность — Связь»(ERD)

Это модель предметной области, которая используется на этапе концептуального проектирования.

Модель использует три основных элемента: сущность, атрибут и связь.

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

Тип сущности определяет набор однородных объектов, а экземпляр сущности — конкретный объект в наборе.

Каждый тип сущности обладает одним или несколькими атрибутами.

Каждому типу сущности должно быть дано уникальное имя. К одному и тому же имени должна всегда применяться одна и та же интерпретация.

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

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

Атрибут — это поименованная характеристика сущности, которая принимает значения из некоторого множества значений.

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

Основное назначение атрибута — описание свойства сущности, а также идентификация экземпляров сущности.

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

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

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

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

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

Связь «один — к — одному» (1:1)

Когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности Б, и наоборот. Связь двунаправленная.

Связь «один — ко — многим» (1:М)

Это такой тип связи, когда каждому экземпляру сущности А может соответствовать ни одного, один или несколько экземпляров сущности Б, однако каждому экземпляру сущности Б соответствует один и только один экземпляр сущности А.

Связь «многие — к — одному» (М:1)

Это отображение обратно предыдущему.

Связь «многие — ко — многим» (отображение М:N)

Это такой тип связи, при котором каждому экземпляру сущности А может соответствовать ни одного, один или несколько экземпляров сущности Б, и наоборот.

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

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

При моделировании используются следующие общие правила:

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

Структурный подход при разработке инфологической модели

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

Моделирование локальных представлений

Выбор локального представления зависит от масштабов предметной области. Для удобства проектирования желательно использовать в отдельных локальных представлениях шесть — семь сущностей.

1. Формулирование сущностей

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

Каждой выбранной сущности должно быть присвоено четкое наименование. Общее их количество не должно быть большим.

2. Выбор идентифицирующего атрибута для каждой сущности.

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

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

3. Назначение сущностям описательных атрибутов

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

4. Спецификация связей

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

Рассмотрим понятие класс принадлежности сущности .

Если каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является обязательным. Это отмечается на ER-диаграмме черным кружком, помещённым в прямоугольник, смежный с прямоугольником сущности А.

Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности является необязательным. Это отмечается на ER-диаграмме черным кружком, помещённым на линии связи возле прямоугольника сущности А.

Правила преобразования ER-диаграмм в реляционные таблицы

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

Для каждой сущности создается таблица. Причем каждому атрибуту сущности соответствует столбец таблицы.

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора – тип связи и класс принадлежности сущности. Изложим их.

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

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

Правило 3: Если связь типа 1:1 и класс принадлежности обеих сущностей необязательный, то необходимо построить три таблицы — по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Правило 4: Если связь типа 1:М и класс принадлежности сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М.

Правило 5: Если связь типа 1:М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы — по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Правило 6: Если связь типа М:N, то необходимо построить три таблицы — по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Вопросы для самоконтроля:

1. Что называется концептуальной моделью?
2. Какие базовые понятия используются на этапе концептуального проектирования?
3. Какие задачи решаются на этапе концептуального проектирования?
4. Перечислите шаги концептуального проектирования.
5. Что называется сущностью и экземпляром сущности?
6. Что называется атрибутом сущности и экземпляром атрибута?
7. Что называется связью между сущностями?
8. Дайте определение понятию «класс принадлежности сущности».
9. На какие факторы опираются правила генерации таблиц из ER-диаграмм?
10. Опишите типовую пошаговую процедуру преобразования диаграммы «сущность — связь» в реляционную схему базы данных.

Лекция 9. Нормализация БД

1. Понятие нормализации
2. Первая нормальная форма
3. Вторая нормальная форма
4. Третья нормальная форма
5. Высшие нормальные формы

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

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

Нормализация – это процесс разделения информации на структурные единицы, т.е. таблицы.

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

В теории реляционных баз данных вводятся понятия так называемых “нормальных форм” — требований к организации данных в таблицах.

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

Так же можно сказать, что процесс нормализации представляет собой приведение таблиц к требуемому уровню нормальности: первый, второй и третий. Каждый уровень нормальности соответствует определённой нормальной форме.

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

Первая нормальная форма (1НФ)

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

Вторая нормальная форма (2НФ)

Говорят, что таблица находится во второй нормальной форме, если она находится в 1НФ и каждый не ключевой столбец полностью зависит от первичного ключа. Другими словами, значение каждого поля должно полностью определяться значением первичного ключа. Важно отметить, что зависимость от первичного ключа понимается именно как зависимость от ключа целиком, а не от отдельной его составляющей (в случае составного ключа).

Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующую последовательность действий:

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

Третья нормальная форма (3НФ)

Говорят, что таблица находится в 3НФ, если она соответствует 2НФ и все не ключевые столбцы взаимно независимы.

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

Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующую последовательность действий:

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

Высшие нормальные формы

В теории реляционных баз данных рассматриваются и формы высших порядков — нормальная форма Бойса — Кодда, 4НФ, 5НФ и даже выше. Большого практического значения эти формы не имеют, и разработчики, как правило, всегда останавливаются на 3НФ.

Вопросы для самоконтроля:

1. Назовите цели нормализации.
2. Чем опасно избыточное дублирование информации?
3. Назовите основные свойства нормальных форм.
4. Какие ограничения таблиц относят к 1НФ, 2НФ и 3НФ?
5. Приведите примеры таблиц, соответствующих и не соответствующих требованиям нормальных форм.

Лекция 10. Средства проектирования структур БД

1. Классификация СУБД
2. Требования к СУБД
3. Общая характеристика и классификация CASE-средств
4. Основные характеристики и возможности СУБД Access
5. Типы данных СУБД Access
6. Создание новой базы данных

Классифицировать СУБД можно по следующим признакам:

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

Требования к СУБД

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

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

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

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

Общая характеристика и классификация CASE-средств

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

Это способствовало появлению программно-технологических средств, реализующих CASE-технологию (Computer Aided Software Engineering) создания и сопровождения ИС. Под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

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

Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

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

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

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям.

Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и включает следующие основные типы:

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

Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает в себя:

• отдельные локальные средства, решающие небольшие автономные задачи (tools),
• частично интегрированные средства, охватывающие большинство этапов жизненного цикла ИС (toolkit)
• полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

• применяемым методологиям и моделям систем и БД;
• степени интегрированности с СУБД;
• доступным платформам.

Основные характеристики и возможности СУБД Access

СУБД Access (фирма Microsoft) имеет достаточно высокие скоростные характеристики и входит в состав чрезвычайно популярного в нашей стране и за рубежом пакета Microsoft Office. Набор команд и функций, предлагаемых разработчикам программных продуктов в среде Access, по мощи и гибкости отвечает большинству современных требований к представлению и обработке данных. В Access поддерживаются разнообразные всплывающие и многоуровневые меню, работа с окнами и мышью, реализованы функции низкоуровневого доступа к файлам, управления цветами, настройки принтера, представления данных в виде электронных таблиц и т. п. Система также обладает средствами быстрой генерации экранов, отчетов и меню, поддерживает язык управления запросами SQL, имеет встроенный язык Visual Basic for Applications (VBA), хорошо работает в сети. СУБД Access позволяет использовать другие компоненты пакета Microsoft Office, такие как текстовый процессор Word for Windows, электронные таблицы Excel и т.д.

Приведем некоторые из средств Microsoft Access, существенно упрощающие разработку приложений.

1. Процедуры обработки событий и модули форм и отчетов. На встроенном языке VBA можно писать процедуры обработки событий, возникающих в формах и отчетах. Процедуры обработки событий хранятся в модулях, связанных с конкретными формами и отчетами, в результате чего код становится частью макета формы или отчета. Кроме того, существует возможность вызова функции VBA свойством события.
2. Свойства, определяемые в процессе выполнения. С помощью макроса или процедуры обработки событий можно определить практически любое свойство формы или отчета в процессе выполнения в ответ на возникновение события в форме или отчете.
3. Модель событий. Модель событий, похожая на используемую в языке Microsoft Visual Basic, позволяет приложениям реагировать на возникновение различных событий, например нажатие клавиши на клавиатуре, перемещение мыши или истечение определенного интервала времени.
4. Использование обработки данных с помощью VBA. С помощью языка VBA можно определять и обрабатывать различные объекты, в том числе, таблицы, запросы, поля, индексы, связи, формы, отчеты и элементы управления.
5. Построитель меню. Предназначен для помощи при создании специальных меню в приложениях. Кроме того, специальные меню могут содержать подменю.
6. Улучшенные средства отладки. Помимо установки точек прерывания и пошагового выполнения программ на языке VBA, можно вывести на экран список всех активных процедур.
7. Процедура обработки ошибок. Помимо традиционных способов обработки ошибок возможно использование процедуры обработки события Error для перехвата ошибок при выполнении программ и макросов.
8. Улучшенный интерфейс защиты. Команды и окна диалога защиты упрощают процедуру защиты и смены владельца объекта.
9. Программная поддержка механизма OLE. С помощью механизма OLE можно обрабатывать объекты из других приложений.
10. Программы-надстройки. С помощью VBA можно создавать
    программы-надстройки, например нестандартные мастера и построители. Мастер — средство Microsoft Access, которое сначала
    задает пользователю вопросы, а затем создает объект (таблицу,
    запрос, форму, отчет и т.д.) в соответствии с его указаниями.

Диспетчер надстроек существенно упрощает процедуру установки программ-надстроек в Microsoft Access.

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

Типы данных СУБД Access

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

🔥 Видео