Размещено на http://www.allbest.ru/

Белорусский национальный технический университет

Факультет маркетинга, менеджмента, предпринимательства

Кафедра «Маркетинг»

КОНТРОЛЬНАЯ РАБОТА

по дисциплине «Компьютерные информационные технологии»

специальности «Экономика и управление на предприятии»

Тема: «Технологии проектирования и реализации базы данных в СУБД MS ACCESS»

Минск 2015



ВВЕДЕНИЕ

проектирование документирование реляционный целостность

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



1. ОРГАНИЗАЦИЯ ВЫПОЛНЕНИЯ КОНТРОЛЬНОЙ РАБОТЫ

1.1 Цели и задачи контрольной работы

Целью выполнения контрольной работы является:

- закрепление получаемых теоретических знаний;

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

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

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

- освоение правил оформления работы в соответствии с требованиями, установленными стандартом высшего учебного заведения (вуза).

Контрольная работа состоит из двух частей: теоретическая и практическая.

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

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

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

1.2 Содержание, структура, требования к оформлению работы

Студенты, обучающиеся по специальности «Экономика и управление на предприятии», в качестве самостоятельной работы по закреплению материала по дисциплине «Компьютерные информационные технологии» выполняют контрольную работу на тему «Технологии проектирования и реализации базы данных в СУБД MS ACCESS».

Структура контрольной работы должна включать:

· Титульный лист.

· Содержание, в котором перечисляются все разделы работы.

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

· Основная часть

Ш Ответ на теоретический вопрос. Ответ на вопрос должен составлять по объему 3 - 4 машинописные страницы.

Ш Проектирование БД

Анализ предметной области и составление спецификаций к данным

Построение концептуальной и логической модели данных.

Физическая модель данных.

Ш Разработка приложения по работе с БД (обоснование выбора СУБД, проектирование запросов, форм, отчетов и т.д)

Назначение объектов.

Структура приложения.

Руководство пользователя.

· Заключение.

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

· Приложения (при необходимости).

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

Контрольная работа должна быть выполнена на стандартной белой бумаге формата А4 с одной стороны листа; шрифт Times New Roman, черного цвета с высотой 12-14 пт с одинарным междустрочным интервалом. Абзацные отступы - 15 мм. Отступы первой строки 0,5 см. Выравнивание текста по ширине. Математические формулы должны быть оформлены с помощью встроенных средств стандартного текстового редактора.

При выполнении отчета по контрольной работе должны быть установлены стандартные поля:

ѕ Левое - 30 мм

ѕ Правое - 15 мм

ѕ Верхнее и нижнее - 20 мм.

В конце номеров разделов, подразделов, пунктов точка не ставится. В конце заголовков точка не ставится.

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

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

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

При ссылках на иллюстрации следует писать «… в соответствии с рисунком 3.1».

Иллюстрации должны иметь наименование и, при необходимости, пояснительные данные. Слово Рисунок, номер и наименование помещают после рисунка и пояснительных данных (если имеются), и выравниваются по центру, например, «Рисунок 3.1 - Схема управления предприятием».

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

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

1.3 Защита контрольной работы

Проверка осуществляется преподавателем в соответствии с графиком ее выполнения. К защите обязательно представить электронную версию работы. Работа защищается с использованием компьютера (студент демонстрирует полученные знания и практические навыки работы на компьютере). По результатам защиты выставляется оценка.



2. КРАТКИЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ И ТЕРМИНОЛОГИЯ

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

К ключевым факторам, определяющим развитие СУБД, относятся следующие:

? увеличение объемов данных и появление новых стандартов представления и обмена данными;

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

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

2.1 Понятие предметной области

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

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

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

2.2 Этапы проектирования базы данных

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

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

На этапе логического проектирования производится организация выделенных данных в форму, принятую в выбранной СУБД. Целью логического проектирования является преобразование концептуальной модели в логическую. Для реляционной БД этот этап состоит в разработке структуры объектов, определении связей между ними и выявлении ключевых реквизитов. Результат - построение диаграмм «сущность-связь» (Entity Relationship - ER-диаграмм). Далее для построения оптимальной структуры базы данных проводится процесс нормализации.

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

2.3 Основные понятия ER-диаграмм

Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity Relationship, диаграммы «сущность-связь»). ER-диаграмма позволяет графически представить все элементы логической модели согласно простым, интуитивно понятным, но строго определенным правилам - нотациям.

Термины, которыми оперирует реляционная модель данных, имеют соответствующие «табличные» синонимы, представленные в таблице 1.



Таблица 1 - Соответствие реляционных и табличных терминов

Реляционный термин	Соответствующий «табличный» термин
База данных	Набор таблиц
Схема базы данных	Набор заголовков таблиц
Отношение	Таблица
Заголовок отношения	Заголовок таблицы
Тело отношения	Тело таблицы
Атрибут отношения	Наименование столбца таблицы
Кортеж отношения	Строка таблицы
Степень (арность) отношения	Количество столбцов таблицы
Мощность отношения	Количество строк таблицы
Домены и типы данных	Типы данных в ячейках таблицы

Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как Преподаватель, Студент, Отдел.

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

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

Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности Преподаватель могут быть такие атрибуты как Табельный номер, Фамилия, Имя, Отчество, Должность, Зарплата и т. п.

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

Определение 5. Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею. Например, связи между сущностями могут выражаться следующими фразами - «ПРЕПОДАВАТЕЛЬ может вести несколько ПРЕДМЕТОВ», «каждый СТУДЕНТ обязан числиться ровно в одной ГРУППЕ».

Каждая связь может иметь один из следующих типов связи: «один-к-одному», «один-ко-многим» или «многие-к-одному», «многие-ко-многим».

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

2.4 Способы документирования ER-модели

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

Метод моделирования «сущность-связь» был предложен С. Ченом в 1976 году. В диаграммах Чена информационные объекты (сущности) изображаются прямоугольниками, связи - ромбами или шестиугольниками, атрибуты - овалами. Сущности соединяются линиями, над которыми могут проставляться степени связи (1 или буква М) и необходимые пояснения.

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

Построение ER-диаграмм, как правило, ведется с использованием CASE-средств, например в MS Office Visio или в ERwin.

В таблице 2 приведены обозначения для двух способов документирования

Таблица 2 - Способы документирования ER-модели

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

Рисунок 1 - Пример связи «многие-ко-многим»

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

Рисунок 2 - Пример преобразования связи M:N к виду «один-ко-многим»

Рисунок 3 - Пример диаграммы Чена

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

Для каждой сущности предметной области базы данных необходимо:

? получить список атрибутов сущности;

? определить функциональные зависимости;

? определить уникальный идентификатор сущности;

? выполнить нормализацию сущности;

? назначить первичные ключи новых, полученных в результате нормализации сущностей;

? сформировать бизнес-правила поддержки целостности сущности.

Для каждой связи между сущностями необходимо:

? определить степень связи;

? определить обязательность вхождения сущности в связь;

? разрешить связи «многие-ко-многим»;

? сформировать бизнес-правила поддержки целостности связей;

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

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

2.5 Нормализация модели «сущность-связь»

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

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

? первая нормальная форма (1NF);

? вторая нормальная форма (2NF);

? третья нормальная форма (3NF);

? нормальная форма Бойса-Кодда (усиленная 3NF);

? четвертая нормальная форма (4NF);

? пятая нормальная форма (5NF).

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

Нормальные формы основаны на понятии функциональной зависимости.

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

Для приведения сущности к первой нормальной форме следует:

? разделить сложные атрибуты на атомарные;

? перенести в нее все «повторяющиеся» атрибуты;

? выбрать возможный ключ для нового первичного ключа или создать его;

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

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

Для приведения сущности ко второй нормальной форме следует:

? выделить атрибуты, которые зависят только от части первичного ключа,

? поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность.

? установить идентифицирующую связь от прежней сущности к новой.

Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть транзитивной зависимости между неключевыми атрибутами).

Для приведения сущности к третьей нормальной форме следует:

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

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

? установить неидентифицирующую связь от новой сущности к старой.

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

2.6 Основные объекты реляционных БД

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

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

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

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

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

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

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

2.7 Структура таблиц и целостность данных

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

? Какие данные будут храниться в каждой из таблиц?

? Какие колонки будут созданы для хранения данных и какие у них будут имена?

? Какие будут требования к диапазону данных, хранящихся в колонках (какие данные разрешено в них хранить), и какие типы данных должны применяться для каждой из колонок?

? Будут ли иметься колонки, которые могут содержать null-значения, или же вместо этого могут применяться значения по умолчанию?

? Какие колонки станут первичными ключами, а какие - внешними ключами?

? Какие типы ограничений должны использоваться?

? Для какой колонки или колонок должны быть определены индексы?

? Какие пользователи должны иметь доступ к тем или иным таблицам?

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

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

Ограничение NOT NULL задается в описании колонки, чтобы воспрепятствовать вставке null-значений в эту колонку (в противоположность ограничению NULL, которое разрешает присваивать null-значения).

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

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

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

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

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

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

Рисунок 4 - Фрагмент ER-диаграммы

Таблица 3 - Описание таблиц и их атрибутов

Информационный объект (таблица)	Название реквизита	Обозначение реквизита	Признак ключа	Тип данных (размер)	Ограничения
ГЭК	№ ГЭК	ГЭК	Уникальный ключ	Счетчик	Уникальное
	№ приказа	Приказ		Текстовый
Заседание_ГЭК	Код заседания	Код	Уникальный ключ	Счетчик	Уникальное
	№ ГЭК	ГЭК	Поле связи	Числовой (подстановка поля ГЭК из таблицы ГЭК)	Обязательное поле, по умолчанию -1
	Дата и время заседания	Дата		Дата/время
	Тип ГЭК	Вид		Текстовый (подстановка значений ГОС или ГЭК)	3 символа, обязательное поле
	Место заседания	Место		Текстовый	30 символов

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



3. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ БАЗ ДАННЫХ

1 способ: Проектирование на основе бумажных документов.

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

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

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

Рисунок 5 - Пример бланка, на основе которого проектируется база данных

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

Рисунок 6 - ER-диаграмма проектируемой базы данных

Выписываем все реквизиты, даем им имена и определяем функциональные зависимости:

Таблица 5 - Имена и функциональные зависимости реквизитов

Документ	Наименование реквизита	Имя реквизита	Функциональная зависимость
Список преподавателей кафедры	Код кафедры	ККАФ
	Название кафедры	НКАФ
	Телефон	ТЕЛ
	Фото зав.кафедрой	ФОТО
	Таб. номер	ТАБН
	Фамилия, имя, отчество	ФИО
	Должность	ДОЛЖН
	Ученая степень	СТ
	Код кафедры	ККАФ

Полученная информационно-логическая модель (ИЛМ) представлена на рисунке 7.

Рисунок 7 - ИЛМ базы данных «Кафедра»

2 способ: Проектирование на основе имеющейся структуры или внешних данных.

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

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

Рисунок 8 - ИЛМ базы данных «Успеваемость»

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

Из списка полей можно выявить следующие объекты и их атрибуты: Услуга (Наименование, Тариф), Плательщик (Фамилия, Адрес) и Оплата (Код, Дата, Количество: метраж - для квартплаты, объем - за газ и электроэнергию, минуты - за телефон и т. д.). Вычисляемое поле Всего в базу данных не заносится.

Рисунок 9 - Excel-таблица с данными «Коммунальные услуги»

Для проектирования базы данных информационно-логическая модель (ИЛМ) может выглядеть так, как показано на рисунке 10.

Рисунок 10 - ИЛМ базы данных «Коммунальные услуги»

Таблицы MS Access могут строиться на основе импорта данных, в частности из электронных таблиц. Используя эту возможность, вся таблица переносится в базу данных, затем, используя язык SQL, делаются проекции данных в новые таблицы, структура которых продумывается заранее. Затем эти таблицы в Конструкторе описываются ключевыми реквизитами и полями связи. Уточняются (корректируются) типы данных. Важно не потерять исходную информацию, которая была в электронной таблице.

3 способ: Проектирование на основе описания предметной области - общей постановки.

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

Процесс проектирования состоит в следующем:

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

- учет покупок;

? учет ежедневных денежных затрат на покупки;

? учет расходов каждого члена семьи и т. д.

Эти требования и пожелания к разрабатываемой БД записываются в столбик на листе бумаги.

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

Таблица 6 - Выделение реквизитов

3. Необходимо конкретизировать требования к каждому объекту и выявить связи между ними, что показано на рисунке 11.

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

Рисунок 11 - ER-модель и ИЛМ базы данных «Затраты на покупки»

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

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

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



4. ВЫПОЛНЕНИЕ ПРАКТИЧЕСКОГО РАЗДЕЛА

4.1 Теоретический вопрос

1. Трехуровневая модель организации баз данных. Иерархическая модель.

2. Реляционная модель. Базовые понятия модели. Первичный и внешний ключ. Реляционная целостность. Операции реляционной алгебры.

3. Постреляционная модель. Объектно-ориентированная модель. Базовые понятия модели. Объектно-реляционная модель.

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

5. Жизненный цикл базы данных. Требования, предъявляемые к базе данных.

6. Модель «сущность-связь», базовые понятия. ER-диаграммы, Case-средства для их создания. Преобразование ER-модели в реляционную модель данных, правила преобразования.

7. Понятие СУБД. Языковые и программные средства СУБД. Архитектура СУБД. Классификация СУБД. Функциональные возможности СУБД.

8. СУБД. Показатели производительности СУБД. Режимы работы пользователя с СУБД. Тенденции развития СУБД.

9. Базы знаний. Модели представления знаний.

10. Продукционные модели. База фактов. База правил. Работа машины вывода.

11. Фреймы, их виды, структура. Сети фреймов, наследование свойств.

12. Характеристики СУБД: тип, производитель, платформа, функциональные возможности, требуемые ресурсы.

13. Технология создания базы данных. Возможности и типы запросов. Технологии проектирования.

14. Способы проектирования форм. Элементы графического интерфейса форм. Технологии проектирования. Работа с базой данных по форме.

15. Способы проектирования отчетов. Вычисления, сортировка и группировка в отчетах. Технология проектирования. Печать отчета.

16. Язык SQL в СУБД. Назначение, стандарты, достоинства. Структура команды SQL. Типы данных. Выражения.

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

18. Управление транзакциями. Управление доступом к данным. Встраивание SQL в прикладные программы. Диалекты языка SQL в СУБД.

19. Системы удаленной обработки. Системы совместного использования файлов. Архитектура файл/сервер и обработка запросов в ней. Роль настольных СУБД в архитектуре файл/сервер. Обзор настольных СУБД.

20. Клиент/серверные системы. Клиентские приложения, серверы баз данных. Обработка запросов в архитектуре клиент/сервер. Хранимые процедуры и триггеры. Механизмы доступа к внешним базам данных. Обзор серверов баз данных.

21. Системы обработки распределенных баз данных (РаБД). Понятие, архитектура, виды распределенных запросов. Обзор РаСУБД.

22. Хранилища данных и требования к ним. Отличие хранилища данных от базы данных. Витрины данных.

23. Пользователи базы данных. Администратор базы данных, его функции.

24. Защита баз данных. Методы защиты баз данных.

25. Оптимизация работы базы данных.



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

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

Рисунок 12 - Процесс проектирования структуры базы данных в MS Access

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

1. Исследуйте моделируемую информационную среду:

1.1. Определите, откуда и в каком виде поступает информация.

1.2. Как часто информация меняется, кто и как работает с данными.

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

2. Создайте список объектов с их свойствами и атрибутами:

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

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

2.3. Проведите процедуру нормализации: приведите разрабатываемую базу данных к 3-й нормальной форме.

2.4. Задокументируйте свои конструктивные решения в виде диаграммы «сущность-связь» (ER-диаграмма) или информационно-логической модели.

2.5. Создайте макет таблиц и связей между ними.

3. Обоснуйте выбор СУБД и среды разработки клиентского приложения:

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

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

3.3. Разработайте интерфейс клиентского приложения.

4. Создайте базу данных, поместите в нее прототипы данных:

4.1. Разработайте ряд запросов, задокументируйте их в виде SQL-скриптов и опишите полученные результаты.

5. Разработайте оконный интерфейс для демонстрации работы с базой данных:

5.1. Обеспечьте эффективность функционирования, простоту и удобство эксплуатации.

5.2. Разработайте управляющую кнопочную форму.

6. Разработайте отчетные документы для демонстрации работы с базой данных:

6.1. Обеспечьте эффективность представления информации, простоту и удобство просмотра.

6.2. Разработайте отчеты с группировками данных.

7. Проведите тестирование и опишите руководство пользователя по работе с БД.

Варианты тем:

Вариант 1

Спроектировать базу данных «Телефонная компания», основанную на данных квитанций

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

Заполнить данными за несколько месяцев.

Вариант 2

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

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

Вариант 3

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

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

Вариант 4

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

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

Вариант 5

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

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

Вариант 6

Официанты ресторана при расчете с клиентом выдают ему чек с расчетом суммы заказа в соответствии с заказанными по меню блюдами.

Спроектировать базу данных «Ресторан», основанную на этих документах и заполнить ее данными.

Вариант 7

Предприятие поставляет топливо (бензин марок АИ95, АИ92, АИ80 и дизельное топливо) на три заправки. На каждую поставку топлива оформляется накладная.

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

Вариант 8

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

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

Вариант 9

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

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

Вариант 10

Расчетный листок выдается каждому сотруднику в конце месяца.



Спроектировать базу данных «Бухгалтерия предприятия» и заполнить ее данными.

Вариант 11

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

Спроектировать базу данных «Автовокзал» и заполнить ее данными.

Вариант 12

БЕЛТЕЛЕКОМ выдает извещение на оплату предоставляемых услуг.

Спроектировать базу данных «Услуги БЕЛТЕЛЕКОМ» и заполнить ее данными.

Вариант 13

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

Спроектировать базу данных «Кредитование» и заполнить ее данными.

Вариант 14

Разные виды деталей изготавливаются несколькими цехами.

Спроектировать базу данных «Изготовление деталей» и заполнить ее данными за полгода.

Вариант 15

Товары поступают на склад в течение месяца. В конце каждого месяца подводится итоговая сумма товарооборота.

Спроектировать базу данных «Товарооборот» и заполнить ее данными за год.

Вариант 16

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

Спроектировать базу данных «Банковские вклады» и заполнить ее данными.

Вариант 17

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

Спроектировать базу данных «Обменные пункты» и заполнить ее данными за 2 месяца не менее 4 пунктов обмена.

Вариант 18

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



Спроектировать базу данных «Оборудование» и заполнить ее данными.

Вариант 19

На экзамен по каждой группе выдается экзаменационная ведомость.

Спроектировать базу данных «Экзамены» и заполнить ее данными.

Вариант 20

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

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

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

Спроектировать базу данных «Страховая компания» и заполнить ее данными.

Вариант 21

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

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

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

Спроектировать базу данных «Гостиница» и заполнить ее данными.

Вариант 22

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

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

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

Спроектировать базу данных «Ведение заказов» и заполнить ее данными.

Вариант 23

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

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

Спроектировать базу данных «Бюро по трудоустройству» и заполнить ее данными.

Вариант 24

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

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

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

Таблицы

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

Спроектировать базу данных «Нотариальная контора» и заполнить ее данными.

Вариант 25

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

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

...