/
Текст
УДК 004.65
ББК 3 973.233-018.2я73
Б 17
Рекомендовано
Редакционно-издательским советом университета
в качестве учебного издания. План 2008 года
Рецензент
кафедра информационных и сетевых технологий
Ярославского государственного университета им. П.Г. Демидова
Составитель А.В. Зафиевский
Базы данных и СУБД: метод, указания / сост. А.В. Sa-
fi 17 фиевский; Яросл. гос. ун-т.- Ярославль: ЯрГУ, 2008.-
48 с.
В первой части методических указаний даны основные
теоретические понятия баз данных.
Во второй части описана методика построения простых
приложений обработки баз данных и сформулированы об-
щие требования к их созданию, а также рекомендации по
написанию отчета.
В третьей части представлены варианты заданий для
самостоятельной работы студентов по созданию компью-
терных программ, использующих базы данных.
Предназначены для студентов факультета информатики и
вычислительной техники, обучающихся по специальности
010503 Математическое обеспечение и администрирование
информационных систем (дисциплина «Базы данных и
СУБД», блок ОПД), очной формы обучения, а также для
студентов других специальностей, изучающих базы данных
системы управления БД.
УДК 004.65
ББК 3 973.233—018.2я73
© Ярославский государственный
университет, 2008
Предисловие
Умение грамотно работать с современными базами данных
является одним из ключевых требований к любому специалисту в
области компьютерных технологий. Важную роль в приобрете-
нии соответствующих навыков играет практическая работа по
созданию компьютерных программ, использующих технологии
баз данных - информационных систем. Предлагаемое издание
поможет студентам компьютерных специальностей легче освоить
основные понятия баз данных и в ходе разработки простых при-
ложений, взаимодействующих с базами данных, получить полез-
ный опыт создания информационных систем.
1. Основные понятия
1.1. Что такое база данных
Потребность в накоплении и систематизации информации
всегда существовала в человеческом обществе. Долгое время
средством удовлетворения этой потребности служили разнооб-
разные библиотеки и архивы. Развитие библиотечной технологии
привело к созданию различных методов поиска информации в
библиотеках - системам каталогов и указателей, которые обеспе-
чивают структуризацию содержимого библиотеки или архива.
Важно при этом отметить, что знание принципов, по которым по-
строены каталоги, позволяет человеку с той или иной степенью
эффективности найти нужную информацию в библиотеке. Более
того, использование каталога является единственным способом
получения информации из библиотеки.
Развитие компьютерной техники, первоначально применяв-
шейся для сложных научно-технических расчетов, привело к то-
му, что, начиная с середины прошлого века, компьютеры стали
применяться для обработки сначала текстовой информации, а за-
тем - любых ее видов. Перенос обработки информации на ком-
пьютерную базу позволил не только значительно ее ускорить, но
и создать новые производственные технологии, получившие на-
звание информационных (или компьютерных). Основой боль-
шинства этих технологий является электронный архив, имеющий
стандартизованную структуру и методы работы с ним, не тре-
бующие непосредственного участия человека, а также предна-
значенные для использования неопределенным кругом пользова-
телей. Именно такие электронные архивы и называются базами
данных.
Фраза «не требующие непосредственного участия человека»
означает, в частности, что в информационной системе, реали-
зующей ту или иную компьютерную технологию, между базой
данных и человеком-пользователем должны существовать про-
межуточные программные уровни (интерфейсы), которые обес-
печивают доступ пользователя к базе данных в удобной для него
форме на языке той области, в которой он является специали-
стом. Чаще всего используется два таких уровня: системный,
обеспечивающий размещение информации на компьютерных но-
сителях, выполнение базовых (не зависящих от предметной об-
ласти) операций с данными и их оптимизацию, и прикладной,
обеспечивающий взаимодействие с пользователем на привычном
для него языке и реализующий выполнение требуемых ему задач,
использующих базу данных. Совокупность программ системного
уровня принято называть системой управления базой данных
(СУБД).
В ранних базах данных, применявшихся, главным образом, в
сфере управления предприятиями, исходные документы не хра-
нились. Вместо этого из них выбиралась только существенная
информация, которая и подвергалась обработке. Жестко норми-
ровался как формат данных, так и взаимосвязи между ними. Это
привело к созданию методики обработки данных (технологии баз
данных), основанной на использовании так называемых моделей
данных, наибольшее распространение из которых получила реля-
ционная модель.
Вместе с тем дальнейшее развитие компьютерной техники
привело к тому, что стало возможным хранить на компьютерных
носителях не только текстовые документы в виде неструктуриро-
ванных текстов или даже их фотографических изображений, но и
информационные объекты других типов: рисунки, анимацию, ау-
дио- и видеозаписи. В результате возникли базы данных, основ-
ным содержанием которых является неструктурированная ин-
формация, и доступ к которой осуществляется, как и в обычных
библиотеках, по каталогу. В связи с этим принято различать базы
данных, ориентированные на данные, и базы данных, ориентиро-
ванные на документы (под которыми понимается любая неструк-
турированная информация, подлежащая обработке внешними
программными модулями, не входящими, как правило, в состав
СУБД). Разумеется, современные базы данных сочетают оба под-
хода, поэтому имеет смысл говорить лишь об их преимуществен-
ной направленности.
В последнее время в связи с развитием сети Интернет полу-
чили распространение слабоструктурированные (или полуструк-
турированные) базы данных, основанные на языке XML. Струк-
тура документов, хранящихся в этих базах данных, с одной сто-
роны, достаточно хорошо формализована, а с другой - допускает
значительную свободу как в отношении типов данных, так и свя-
зей между элементами данных.
1.2. Реляционная модель данных
Как уже упоминалось, наиболее распространенным типом баз
данных в настоящее время являются реляционные базы данных,
основанные на реляционной модели данных, сформулированной
Е. Коддом в 1969 году. Эта модель почти сразу получила широ-
кое распространение в связи с тем, что допускала обработку дан-
ных не только навигационным методом, требовавшим детального
описания производимых с данными действий, но и с помощью
высокоуровневых операций (например, реляционной алгебры),
позволяющих разработчику сосредоточиться не на деталях взаи-
модействия с базой данных, а на основном алгоритме. К настоя-
щему времени модель Кодда претерпела некоторые изменения,
поэтому, несмотря на сохранение названия «реляционная модель
данных», было бы точнее говорить «модель данных, основанная
на языке SQL».
Основным понятием реляционной модели данных является
отношение (relation), которое можно представлять себе в виде
5
именованной таблицы простейшей структуры с заданным коли-
чеством столбцов, каждый из которых имеет уникальное (в пре-
делах таблицы) имя, и неопределенным количеством строк, среди
которых нет повторяющихся. Важно отметить, что клетки табли-
цы должны содержать атомарные значения, которые обрабаты-
ваются системой управления базой данных как единое целое.
Это, в частности, означает, что, например, при использовании ие-
рархических кодов система не может вести поиск по части кода.
Не допускается также объединение столбцов в группы или объе-
динение нескольких клеток в одну. Надо отметить, что названные
ограничения часто вызывают значительные^ особенно при отсут-
ствии опыта, трудности при первоначальном проектировании
структуры базы данных.
С теоретической точки зрения таблицы реляционной модели
соответствуют информационным объектам, а столбцы таблиц -
свойствам объектов (атрибутам). Структуру таблицы принято на-
зывать схемой отношения и записывать в виде: Имя_таблицы =
(Имя_столбца1, Имя_столбца2, ... ).
Порядок строк и столбцов в таблице обычно считается несу-
щественным. Иногда столбцы таблицы называются полями, а
строки - записями.
Все действия в реляционной модели выполняются только с
таблицами. Даже если результатом операции является одно чис-
ло, оно все равно рассматривается как таблица с одним столбцом
и одной строкой. Предполагается, что порядок строк в таблице не
может быть известен: понятия «первая строка», «следующая
строка» и т.п. отсутствуют. Для идентификации же строк исполь-
зуется понятие ключа, под которым понимается набор столбцов,
значения в которых однозначно определяют строку таблицы. По-
скольку все строки в таблице различны, то, в крайнем случае, в
состав ключа могут входить все столбцы таблицы. На практике,
однако, ключ чаще всего состоит из одного столбца, причем если
в исходных данных подобного столбца нет, то он может быть
введен искусственно (типичный пример - табельный номер).
Разумеется, в таблице может существовать несколько набо-
ров столбцов, значения в которых однозначно определяют строку
таблицы. Все они называются возможными ключами. Решение о
том, какие наборы столбцов являются возможными ключами,
принимается разработчиком базы данных при анализе содержа-
тельной стороны информационной системы (предметной облас-
ти). Например, кроме упомянутого табельного номера, в кадро-
вой таблице ключом может быть набор из фамилии, имени, отче-
ства, адреса и даты рождения сотрудника. Если указать системе
управления базой данных, что набор столбцов является ключом,
то она будет блокировать помещение в таблицу строки с дубли-
рующими значениями ключа. Один из ключей должен быть обя-
зательно указан системе при создании таблицы. Этот ключ назы-
вается первичным ключом (primary key). Другие ключи могут
быть указаны как альтернативные (alternative или unique).
1.3. Связанные таблицы
Информация, хранящаяся в базе данных, является внутренне
взаимосвязанной. Связи между ее элементами могут проявляться
как на уровне атрибутов (столбцов), так и на уровне информаци-
онных объектов (таблиц).
Взаимосвязь таблиц появляется, когда соответствующие ин-
формационные объекты содержат одинаковые атрибуты или
группы атрибутов. Например, если есть таблицы Студент (Но-
мерстуд, ФамилияИО, Дата_рожд, Адрес) и Сессия (Но-
мерстуд, Наимдисц, Оценка) (жирным шрифтом выделен пер-
вичный ключ), то видно, что столбцы Номер студ в той и другой
таблицах содержат одинаковые по смыслу значения. Если по зна-
чениям данных в строке одной таблицы однозначно определяется
строка другой таблицы, то такой случай считается «правильным»,
а таблицы называются связанными по типу 1:М. При этом первая
таблица называется главной (или родительской - master), а вторая
- подчиненной (или дочерней - detail). В приведенном примере
таблица Студент является родительской, а Сессия - дочерней.
Для указания системе управления базой данных, что таблицы
связаны по типу 1:М, в дочерней таблице столбцы связи описы-
ваются как внешний ключ (foreign key) и указывается ее родитель-
ская таблица. В родительской таблице столбцы связи должны яв-
ляться первичным ключом. В нашем примере внешним ключом
таблицы Сессия является столбец Номер студ.
Чаще всего внешний ключ дочерней таблицы совпадает с
первичным ключом родительской таблицы, в то время как в до-
черней таблице он может как входить, так и не входить в состав
первичного ключа. В первом случае связь между таблицами на-
зывается идентифицирующей, во втором - неидентифици-
рующей.
Указание системе взаимосвязи таблиц позволяет ей блокиро-
вать добавление строк в дочернюю таблицу при отсутствии соот-
ветствующих строк в родительской, и наоборот, удаление строк в
родительской таблице при наличии соответствующих строк в до-
черней.
Если некоторым строкам первой таблицы соответствует не-
сколько строк второй, а некоторым строкам второй таблицы - не-
сколько строк первой, то такая связь называется относящейся к
типу М:М и подлежит корректировке путем реструктуризации
таблиц. Поясним эту процедуру на примере.
Пусть имеется таблица Расписание (Кодпреп, Дата,
Наим_дисц, Ном_гр, Ном ауд). Ясно, что она связана с таблицей
Сессия через столбец Наим_дисц по типу М:М: с одной стороны,
одну и ту же дисциплину сдают разные студенты, а с другой - эк-
замен по одной и той же дисциплине для разных групп может
проходить в разные дни. Для того чтобы правильно сформиро-
вать систему связи этих таблиц, можно ввести дополнительную
таблицу Личн jmcmic (Номер студ, Наимдисц, Код_преп, Да-
та). содержащую первичные ключи обеих таблиц и являющуюся
дочерней для обеих первоначальных таблиц.
Очевидно, описанная процедура вполне может быть автома-
тизирована, и большинство систем автоматизации проектирова-
ния выполняет ее автоматически.
Тем не менее, несмотря на формальную правильность, при-
веденная схема демонстрирует пример неудачного проектирова-
ния базы данных, поскольку для всех студентов одной группы
пришлось бы многократно вводить в таблицу Личнjpacnuc одну и
ту же дату экзамена. Более эффективной была бы следующая
схема базы данных:
Студент (Номер_студ, Фамилия ИО, Датарожд, Адрес,
Ном_гр);
8
Расписание (Наим_дисц, Номгр, Кодпреп, Дата,
Номауд);
Сессия (Номер студ, Наимдисц, Ном гр, Оценка).
При этом таблица Сессия должна быть объявлена дочерней
по отношению к таблице Список по внешнему ключу Но-
мер_студ и дочерней по отношению к таблице Расписание по
внешнему ключу (Наим дисц, Ном гр). Это, в частности, исклю-
чит возможность ввода в таблицу Сессия ошибочных значений
номера студента и наименования дисциплины.
1.4. Нормализация базы данных
Под нормализацией понимается процедура приведения схе-
мы базы данных, а также связей между таблицами к некоторому
каноническому виду с целью сокращения избыточности данных и
устранения аномальных эффектов определенного типа. Принято
процесс нормализации подразделять на этапы, называемые при-
ведением к нормальным формам 1НФ (первая нормальная фор-
ма), 2НФ, ЗНФ, НФБК (нормальная форма Бойса-Кодда), 4НФ,
5НФ. При этом каждая следующая форма накладывает все более
строгие ограничения на базу данных.
Отметим, что процесс нормализации носит в значительной
степени теоретический характер. При наличии хотя бы неболь-
шого опыта проектировщик данных практически сразу создает
схему базы данных, удовлетворяющую требованиям третьей
нормальной формы. Аналогичным образом работают и системы
автоматизации проектирования структуры БД: процесс проекти-
рования построен таким образом, что на выходе получается база
данных, удовлетворяющая условиям ЗНФ. Тем не менее знание
процедуры нормализации необходимо хотя бы по той причине,
что в ходе модификации структуры БД выполнение требований
нормальных форм может быть нарушено.
Перейдем теперь к описанию нормальных форм. Определе-
ние первой нормальной формы по существу совпадает с опреде-
лением отношения: таблица находится в 1НФ, если она имеет
простой вид (отсутствует группировка столбцов и клеток), значе-
ние в каждой клетке является атомарным и выделен первичный
ключ, т.е. группа столбцов, значения в которых однозначно опре-
9
деляют значения в остальных (неключевых) столбцах. От опреде-
ления отношения это отличается лишь тем, что в 1НФ фиксиру-
ется первичный ключ.
Понятие атомарности не является абсолютным: значение,
атомарное для одной предметной области, может быть неатомар-
ным для другой. Можно руководствоваться общим принципом,
что значение неатомарно, если при обработке данных использу-
ются части этого значения. Например, если атрибут «адрес», со-
держащий названия города, улицы и т.д., используется только для
печати на конвертах, то он атомарен, если же осуществляется
сортировка по городам, то нет.
Нормальные формы более высокого порядка базируются на
понятии функциональной зависимости, которую можно описать
следующим образом.
Говорят, что атрибут В функционально зависит от атрибутов
А1, А2,..., Ак, если значение атрибута В однозначно определяется
значениями атрибутов А1,..., Ак Обычно это записывается в виде
Ак —> В. В частности, от любого возможного ключа табли-
цы функционально зависят все остальные (неключевые) столбцы.
Так же, как и при выделении возможных ключей, функциональ-
ные зависимости выявляются разработчиком в ходе содержа-
тельного анализа предметной области.
Наличие функциональных зависимостей приводит к эффек-
там, называемым аномалиями обновления и избыточностью дан-
ных.
Рассмотрим в качестве примера таблицу Ceccl со структурой
вида Ceccl (Номерстуд, Наимдисц, ФамилияИО, Да-
та_рожд, Адрес, Фам_преп, Кафедра, Оценка). Столбцы этой
таблицы связаны следующими функциональными зависимостя-
ми:
Номер студ Фамилия ИО, Дата рожд, Адрес;
Номер студ, Наим дисц —> Фам преп, Кафедра, Оценка;
Фампреп -» Кафедра.
К аномалиям обновления относятся следующие особенности
этой структуры:
• если мы хотим вставить только личные данные студента
(фамилию, адрес и т.д.), то мы не можем этого сделать, если у нас
нет информации хотя бы об одном сданном этим студентом экза-
мене (аномалия вставки);
• если мы хотим удалить информацию об экзамене (если, на-
пример, она была введена ошибочно) и этот экзамен у студента
был единственным, то при этом будет удалена вся личная ин-
формация о студенте (аномалия удаления).
Кроме того, информация в таблице является избыточной', все
личные сведения о студенте должны повторяться в каждой стро-
ке, относящейся к этому студенту, но содержащей информацию о
различных экзаменах. При этом соответствующие личные данные
должны быть идентичны: если мы, например, изменяем инфор-
мацию об адресе студента, то это изменение должно быть одина-
ковым образом выполнено для всех строк, относящихся к этому
студенту. Это противоречит принципу неизбыточности, в соот-
ветствии с которым информация в базе данных должна храниться
однократно.
Процедура нормализации предназначена для устранения ука-
занных особенностей. Она позволяет устранить некоторые ано-
малии обновления и сократить избыточность в базе данных. Пер-
вым ее шагом (если не считать преобразования таблиц к 1НФ)
является переход ко второй нормальной форме (2НФ) - устране-
ние частичных функциональных зависимостей от первичного
ключа.
Говорят, что отношение находится во второй нормальной
форме, если оно имеет первую нормальную форму и в нем отсут-
ствуют неключевые атрибуты, функционально зависящие лишь
от части первичного ключа.
В нашем примере столбцы ФамилияДИО, Дата_рожд, Адрес
функционально зависят только от столбца Номер студ и не зави-
сят от столбца Наимдисц, также входящего в состав первичного
ключа. Это приводит к очевидным аномалиям обновления и из-
быточности данных.
Приведение таблицы ко второй нормальной форме состоит в
замене исходной таблицы в базе данных на пару таблиц, связан-
ных отношением родительская-дочерняя. При этом в родитель-
скую таблицу помещается часть первичного ключа (которая ста-
новится первичным ключом родительской таблицы) и функцио-
нально зависящие от него столбцы, а в дочернюю ~ весь первич-
ный ключ и оставшиеся неключевые атрибуты. В качестве внеш-
него ключа дочерней таблицы объявляется часть первичного
ключа, вошедшая в родительскую таблицу. Соответственно, связь
между таблицами в этом случае является идентифицирующей.
В приведенном примере схема базы данных после преобразо-
вания будет выглядеть следующим образом:
Студент (Номер_студ, ФамилияИО, Дата_рожд, Адрес);
Сесс2 (Номерстуд, Наим_дисц, Фампреп, Кафедра, Оцен-
ка).
Обе таблицы находятся во второй нормальной форме, однако
вторая таблица по-прежнему подвержена аномалиям обновления
и избыточности данных. Например, если преподаватель перехо-
дит с одной кафедры на другую, то мы должны поменять назва-
ние кафедры во всех строках с фамилией этого преподавателя.
Связано это с тем, что столбец Кафедра функционально зависит
от столбца Фам_преп. который, в свою очередь, функционально
зависит от первичного ключа. Зависимости, в которых неключе-
вые столбцы (атрибуты) зависят от других неключевых столбцов,
называются транзитивными.
Таблицы, в которых транзитивные зависимости отсутствуют,
называются приведенными к третьей нормальной форме (ЗНФ).
Для приведения таблицы к третьей нормальной форме она
также заменяется на пару таблиц, связанных отношением роди-
тельская-дочерняя. При этом в родительскую таблицу помеща-
ются неключевые столбцы, от которых зависят другие неключе-
вые столбцы (становясь при этом первичным ключом родитель-
ской таблицы) и функционально зависящие от них столбцы, а в
дочернюю ~ все столбцы, за исключением неключевых столбцов
родительской таблицы. В качестве внешнего ключа дочерней
таблицы объявляются столбцы, образующие первичный ключ ро-
дительской таблицы. В этом случае связь между таблицами явля-
ется неидентифицирующей.
Таблица Сесс2 в нашем примере разбивается следующим об-
разом:
Преподаватель (Фам__преп, Кафедра);
СессЗ (Номерстуд, Наимдисц, Фам преп, Оценка).
Нормальные формы более высокого уровня (Бойса-Кодда,
4НФ, 5НФ) накладывают дополнительные ограничения на воз-
можные данные в таблицах. Познакомиться с ними можно в
учебниках, указанных в списке литературы. Следует, однако, от-
метить, что невыполнение их условий обычно говорит о глубокой
внутренней взаимосвязи данных и недостаточной проработке
предметной области и требует дальнейшего изучения процедур,
применяемых при обработке данных. В относительно простых
системах обычно достаточно проверки выполнения условий пер-
вых трех нормальных форм.
В заключение заметим, что хотя нормализация имеет целью
«улучшение» структуры базы данных, на практике часто оказы-
вается, что полная нормализация приводит к снижению нагляд-
ности структуры данных и эффективности их обработки. Поэто-
му в отдельных случаях целесообразно пожертвовать некоторы-
ми аспектами нормализации, понимая, вместе с тем, что за это
придется платить увеличением избыточности данных и про-
граммной (а не системной) реализацией контроля данных.
2. Общая схема процесса проектирования
2.1. Общая схема
Весь процесс создания информационной системы на основе
базы данных можно разделить на несколько этапов:
• определение требований к системе;
• составление перечня задач;
• составление списка входных и выходных документов;
• проектирование пользовательского интерфейса (экранные
формы и формы документов);
• выбор СУБД и разработка структуры данных;
• описание алгоритмов обработки данных;
• разработка программы (кодирование);
• тестирование.
Не следует считать, что перечисленные этапы должны вы-
полняться строго последовательно. Детальная проработка каждо-
го из них может привести к необходимости изменений в преды-
дущих этапах или к изменению порядка проектирования.
2.2. Требования к системе и перечень задач
Целью этого этапа является формальное описание предмет-
ной области: выделение информационных объектов, принимаю-
щих участие в процессе функционирования системы и описание
их взаимодействия, составление списка действий с этими объек-
тами (запросов), подлежащими реализацйи. Вся дальнейшая раз-
работка информационной системы должна вестись в терминах,
сформированных на этом этапе понятий.
2.3. Входные и выходные документы
Важным элементом любой системы организационного
управления являются документы, как поступающие на обработку
(входные), так и являющиеся результатом ее работы (выходные).
В простейших системах документы того или иного типа могут
отсутствовать, однако в любой достаточно развитой системе со-
вокупность документов предметной области является базой, на
которой строится вся информационная система.
На этапе описания документов следует составить полный пе-
речень документов и их реквизитов, обратив при этом внимание
на тип (текст, число, дата и т.д.) и размер реквизитов, а также на
их соподчиненность. Следует также выделить реквизиты, одно-
значно определяющие документ (ключевые реквизиты). На этом
же этапе следует описать размещение реквизитов на бумажном
носителе (форму документов).
2.4. Пользовательский интерфейс
При разработке пользовательского интерфейса учитываются
результаты предыдущих двух этапов проектирования. При этом
следует в максимальной степени использовать возможности сре-
ды проектирования, в которой ведется разработка. Так, например,
если средой разработки является система Visual Studio, то основ-
ными элементами интерфейса должны быть визуальные компо-
ненты этой системы (меню, поля редактирования, кнопки и др.).
С их помощью следует организовать выполнение требуемых за-
дач, включая ввод входных документов и выдачу выходных до-
кументов.
По возможности следует придерживаться принципа «один
документ - одна экранная форма». Отклонения от этого принци-
па должны обосновываться.
При проектировании интерфейса следует соблюдать единст-
во стиля, заранее выбрав форматы окон, используемые шрифты и
цвета, способы выдачи информационных сообщений и сообще-
ний об ошибках и др.
Весь интерфейс должен быть выполнен на русском языке.
Важным признаком интерфейса является его «дружественность»:
система должна вести себя предсказуемым для пользователя об-
разом и предлагать ему ожидаемый выбор. Не следует заставлять
пользователя вводить длинные строки текста (например, фами-
лию, имя, отчество), если соответствующая информация уже
имеется в системе: при вводе 3 и более символов должны предла-
гаться варианты. Альтернативой может являться выбор из меню.
Там, где это возможно, должны автоматически проставляться
номера (например, номера счетов-фактур) и даты (заключения
сделок, выплаты).
2.5. Выбор СУБД и разработка структуры
данных
Выбор СУБД для реализации лабораторной работы доста-
точно произволен. Основными требованиями при этом являются
следующие:
• СУБД должна быть совместима со стандартом SQL’92 в
предположении, что все обращения к базе данных будут произ-
водиться только на этом языке;
• сервер базы данных должен присутствовать на компьютере,
на котором предполагается демонстрация работы;
• база данных должна представлять собой файл, который
может быть размещен в произвольном каталоге демонстрацион-
ного компьютера.
Допускается использование СУБД Jet (база данных Access),
входящей в состав Windows, но без использования Access как
среды программирования.
Проектирование структуры данных желательно вести с по-
мощью какой-либо CASE-системы (обычно входящей в состав
СУБД), представляя результат проектирования в виде диаграмм.
При описании структуры базы данных следует указать, в ка-
кой степени она соответствует требованиям нормализации.
2.6. Описание алгоритмов и кодирование
При описании системы следует ясно (хотя и не подробно) из-
ложить алгоритмы, реализующие ее основные функциональные
возможности.
Программная реализация должна быть выполнена на каком-
либо процедурном языке программирования. Допускаются C++.
С#, Паскаль (Delphi), Java. Все обращения к базе данных должны
выполняться только на языке SQL. Не допускается прямое обра-
щение к таблицам СУБД. Как программный модуль, так и база
данных не должны быть привязаны к определенному месту и
должны либо допускать настройку на расположение в заданной
директории, либо работать в текущем каталоге.
Особое внимание следует обратить на обработку ошибок.
Предпочтительным, разумеется, является вариант, когда пользо-
ватель за счет правильно спроектированного интерфейса не име-
ет возможности допустить ошибку (защита от «дурака»), однако,
в случаях, когда это невозможно, ошибка должна быть обработа-
на с выдачей диагностики на русском языке.
В процессе кодирования системы следует предусмотреть,
кроме основного функционала, реализацию всех сервисных воз-
можностей (например, добавление и удаление записей). Разрабо-
танная система должна функционировать без использования кон-
соли СУБД (за исключением, возможно, привязки к демонстра-
ционному компьютеру).
2.7. Тестирование системы
Заключительным этапом разработки системы должно являть-
ся тестирование. Следует разработать тестовые наборы данных и
методики тестирования, обеспечивающие всесторонний анализ
функционирования системы. Основные таблицы базы данных
должны содержать не менее 100 записей. По крайней мере одна
из таблиц должна иметь значительные размеры (до 1 млн запи-
сей) для определения временных и объемных характеристик сис-
темы.
В ходе тестирования должно быть выявлено максимальное
количество ошибок и дописаны программы обработки этих оши-
бок. В частности, следует обеспечить время реакции системы на
любой запрос не более 10 сек, а на простые запросы - не более 1
сек.
2.8. Отчет о лабораторной работе
При составлении отчета необходимо описать основные этапы
проектирования: постановку задачи, основные функциональные
возможности системы, входные и выходные документы, выбор
СУБД и среды разработки, схему базы данных, основные экран-
ные формы, методику составления тестовых наборов данных, а
также привести распечатку 2-3 основных процедур.
3. Варианты заданий
для самостоятельной работы
Ниже приводятся примеры заданий для самостоятельной рабо-
ты. Выполненная работа оценивается по следующим параметрам:
• правильность понимания и реализация требований задания
(наличие или отсутствие требуемых функций);
• степень реализации дополнительных функций;
• владение построением пользовательского интерфейса и сте-
пень его продуманности, удобства и эффективности;
• качество структуры базы данных;
• владение построением SQL запросов;
• оценка качества тестовых данных;
• качество представленного описания.
Студент может также выбрать собственную тему, согласовав
ее с преподавателем и подготовив описание, аналогичное приве-
денным ниже, либо добавить дополнительную функциональность
в имеющиеся задания.
№ 1 «Книга о вкусной и здоровой пище»
Поваренная книга состоит из нескольких разделов (не менее 3), в
каждом из которых содержатся рецепты различных блюд (не менее 10).
Каждое характеризуется набором продуктов и способом приготовления.
Продукты характеризуются названием, калорийностью, «экзотичностью» и
др. Нужно также продумать переход от стандартных единиц измерения к
ложкам, стаканам и т.п.
Основное задание:
1. Поиск нужного блюда.
2. Поиск блюда из определенных продуктов.
3. Выдать меню с заданной калорийностью.
4. Выдать меню из «доступных» продуктов.
5. Выдать диетическое меню с учетом способа приготовления
(духовка, микроволновка, жарка и т.п.) и набора продуктов.
Дополнительные задания:
1. Составить разнообразное меню на неделю.
2. Праздничное меню.
3. Учесть быстроту и доступность приготовления.
№ 2 «Телефонная книга частных лиц»
Телефонный справочник частных лиц содержит информацию
о фамилиях и инициалах абонентов, их номерах телефонов, а
также дополнительную информацию (адреса, электронную почту,
ICQ и т.п.).
Основное задание:
1. Обеспечить быстрый поиск нужного телефона по фамилии
или имени и в различных категориях: друзей, деловых партнеров,
родственников и т.п.
2. Учесть наличие у одного лица нескольких номеров теле-
фонов: рабочих, домашних, мобильных.
3. Обеспечить обратный поиск: определение абонента по но-
меру телефона.
Дополнительные задания:
1. Реализовать ввод и хранение дополнительной информации
(адресов, фотографий и др.).
2. Реализовать поиск по дополнительной информации.
3. Хранить историю смены номеров с возможностью поиска
по старому номеру.
№ 3 «Телефонная книга организаций»
Телефонный справочник организаций содержит информацию
о наименованиях организаций, профиле их деятельности, место-
положении, а также дополнительную информацию (электронную
почту, фамилию директора и т.п.).
Основное задание:
1. Обеспечить быстрый поиск нужного телефона по названию
и в различных категориях: по профилю, по местоположению
и т.п.
2. Учесть наличие нескольких номеров с различной функ-
циональностью (например, офис, склад и т.д.).
3. Обеспечить обратный поиск: определение абонента по но-
меру телефона.
Дополнительные задания:
1. Реализовать ввод и хранение дополнительной информации
(прайс-листов, фотографий и др.).
2. Реализовать поиск по дополнительной информации.
3. Хранить историю смены номеров с возможностью поиска
по старому номеру.
№ 4 «Домашняя библиотека»
Домашняя библиотека состоит из нескольких разделов: де-
тективы, фантастика, приключения, учебники, школьная литера-
тура, научная литература, «женские истории» и др. (не менее 3-х
разделов). Книги стоят на пронумерованных полках в соответст-
вии с разделами. Каждая книга характеризуется названием, авто-
ром, годом и местом издания и т.п. Нужно продумать, как отра-
зить принадлежность одной книги к нескольким разделам и как
«оформить» сборник произведений, учитывая возможность на-
хождения одного произведения в нескольких книгах.
Основное задание:
1. Поиск книги на полках по названию и/или автору.
2. Поиск произведения по названию.
3. Выбор всех произведений заданного автора с указанием
сборников и полок.
4. Выбор всех книг из раздела по заданному разделу.
5. Подсчет произведений по автору и/или по разделу (без по-
второв).
6. Вывод информации о «дубликатах».
Дополнительные задания:
1. Учесть иллюстративное оформление и стоимость книг.
2. Добавить внешний вид обложки.
3. Предусмотреть возможность ввода комментариев к произ-
ведениям и поиска по комментариям.
4. Учесть возможность передачи книги друзьям, не теряя ин-
формации о размещении книги на полках.
№ 5 «Домашняя дискотека»
Домашняя дискотека состоит из дисков различных катего-
рий: фильмы различных жанров, аудиодиски (обычные и mp3),
аудиокниги, диски с документацией, диски с программами и др.
Диски находятся в различных местах (в стойках, на полках и т.д.).
Каждый диск описывается различными характеристиками, зави-
сящими от категории диска. Нужно продумать структуру диско-
теки и характеристики каждой категории дисков.
Основное задание:
1. Поиск дисков по наименованию какой-либо характеристи-
ки.
2. Отбор всех дисков, удовлетворяющих заданному набору
характеристик,
3. Вывод разнообразных статистических сведений.
4. Вывод информации о «дубликатах».
Дополнительные задания:
1. Учесть вид носителя (CD-ROM, CD-R, DVD, BD), издателя
и стоимость дисков.
2. Добавить сканы вкладышей.
3. Предусмотреть возможность ввода комментариев к дискам
и поиска по комментариям.
4. Учесть возможность передачи дисков друзьям.
№ 6 «Библиотека программных продуктов»
Каждый программный продукт характеризуется названием,
категорией функциональности, производителем, требуемыми
системными характеристиками и размером занимаемой памяти на
дисках, стоимостью и т.д.
Основное задание:
1. Найти месторасположение заданного программного про-
дукта по его названию, функциональной принадлежности, фир-
ме-производителю и вывести полную информацию о нем.
2. Обеспечить возможность ввода и хранения описаний про-
граммных продуктов.
3. Вывести информацию об аналогичных программных про-
дуктах и их характеристиках.
Дополнительные задания:
1. Обеспечить возможность поиска по описаниям программ-
ных продуктов.
2. Проверить совместимость программного продукта с задан-
ной конфигурацией компьютера (с отчетом о возможных причи-
нах несовместимости).
3. Выбрать наиболее подходящий программный продукт за-
данного типа с учетом имеющейся конфигурации компьютера в
пределах заданной стоимости.
4. Предложить варианты комплектации набора программных
продуктов заданных категорий в пределах заданной стоимости.
№ 7 «Помощник диск-жокея»
Диск-жокей располагает богатой фонотекой на пронумеро-
ванных пластинках, кассетах, компакт-дисках по различным му-
зыкальным направлениям: классика, джаз, кантри, соул, рок, поп-
музыка и пр. (не менее 5-ти направлений).
Основное задание:
1. Найти необходимую запись по названию, исполнителю,
автору и т.п., выводя также информацию о возможных повторах.
2. Составить тематическую (по стилю, жанру музыки, по ис-
полнителю, автору текста или композитору и т.п.) подборку или
дискотеку, укладывающуюся в определенные временные рамки.
3. Составить список записей на «выходную» дискотеку с уче-
том требований клиента к стилю музыки, исполнителям, к чере-
дованию мелодий . (быстрая-медленная, русскоязычная-
иноязычная, микст и т.п.). Организовать поиск выбранных запи-
сей из фонотеки. Определить оптимальней вариант их записи на
аудио диски, учитывая время их звучания.
Дополнительные задания:
1. Ввести «рейтинг» популярности мелодий и учитывать его
при составлении программ.
2. Предусмотреть возможность ввода комментариев к запи-
сям и поиска по комментариям.
3. Вставить музыкальные фрагменты в формате MP3, WAV и др.
№ 8 «Поставка товаров в супермаркет»
Предлагается рассмотреть поставки товаров в супермаркет с
несколькими отделами: 1) продовольственный, 2) хозяйственный,
3) бытовая химия, 4) бытовая электроника, 5) мебельный и др. (не
менее 3-х направлений работы магазина). В каждом отделе име-
ется определенный ассортимент продукции (товар одного наиме-
нования должен быть различных видов!). В супермаркете ведется
учет расчетов с поставщиками, которые представлены несколь-
кими постоянными фирмами-производителями и отдельными
агентами. Поставщики предоставляют сведения: название, юри-
дический адрес, телефон, ассортимент поставляемых товаров, оп-
товые цены, и т.п. Агенты- физические лица предоставляют:
ФИО, адрес, телефон, наименования товаров, цены и т.п.
Основное задание:
1. Поиск поставщика (с указанием его координат) с самой
низкой ценой на заданный товар.
2. Поиск поставщика с самым широким ассортиментом по
заданному отделу.
3. Поиск наиболее выгодного поставщика с учетом ассорти-
мента и необходимого количества товаров.
4. Вывод списка поставщиков, у которых приобретается не-
обходимый набор товаров с учетом их количества и минималь-
ными издержками.
5. Подсчет выплаты поставщикам с разбивкой по видам по-
ставляемого товара за определенный период.
Дополнительные задания:
1. Ввести учет условий оплаты и скидок.
2. Выбирать наиболее выгодные виды и сроки доставки с
учетом суммы сделки.
Примечание:
В общем виде может быть рассмотрена задача автоматизации
работы менеджера по поставкам. При наличии практической ба-
зы можно рассматривать отдел поставок любой фирмы.
№ 9 «Реализация и обслуживание кассовых
аппаратов»
Фирма продает организациям (не менее 10) кассовые аппара-
ты (3-5 марок) и по желанию клиента заключает договоры о по-
следующем техническом обслуживании. Договор об обслужива-
нии заключается на определенный срок (не менее 1 месяца) по
выбору клиента; после окончания срока договора его можно про-
длить. Плата за обслуживание меняется в зависимости от време-
ни заключения договора и его продолжительности. Формы опла-
ты: предоплата и/или помесячная (например, не позднее 10 числа
каждого последующего месяца).
Основное задание:
1. Поиск информации о клиенте.
2. Вывод информации о покупках кассовых аппаратов и за-
ключении договоров на обслуживание за период.
3. Вывод списка клиентов, оплативших вперед на определен-
ный срок.
4. Список должников по запросу на текущий день с выделе-
нием «злостных» неплательщиков.
5. Расчет суммы долга и пени по отдельным клиентам.
Дополнительные задания:
1. Учесть возможность изменения тарифов в связи с модифи-
кацией кассовых аппаратов и расширением рынка услуг.
2. Предусмотреть систему скидок постоянным и добросове-
стным клиентам.
Примечание:
В общем виде можно рассмотреть задачу об оказании клиентам
определенных услуг. Постановка задачи может быть скорректиро-
вана с учетом специфики рассматриваемой фирмы (телефонная
сеть, фирма по продаже и обслуживанию компьютеров и т.п.).
№ 10 «Расчет дополнительных выплат работникам
поликлиники»
Поликлиника оказывает платные услуги (не менее 10 видов)
населению. Денежные средства, вырученные за эти услуги, рас-
пределяются на заработную плату исполнителям и прочие виды
затрат; проценты отчислений на оплату труда работников с каж-
дой услуги различны (определяются видом услуги). Средства на
оплату труда, получаемые от оказания платных услуг, распреде-
ляются между исполнителями пропорционально вкладу в работу
в соответствии с занимаемой должностью (учитывается работа не
только медиков, но и администрации, и технических работников,
и обслуживающего персонала).
Основное задание:
1. Расчет дополнительных выплат сотрудникам поликлиники
за последний месяц.
2. Составление списка работников с указанием их доходов по
отдельным видам услуг.
3. Составление списка работников и расчет их дополнитель-
ной оплаты за определенный период.
4. Окончательный расчет дополнительных выплат отдельного
работника при его увольнении из поликлиники.
Дополнительные задания:
1. Построить рейтинг платных услуг по показателю дохода,
полученного поликлиникой.
2. Рассчитать среднюю сумму, полученную с одного клиента
за определенный период.
3. Предусмотреть возможность изменения распределения до-
полнительных выплат в связи с повышением квалификации ра-
ботников.
№ 11 «Работа деканата»
Методисту деканата необходимо вести учет студентов и их
успеваемости.
Основное задание:
1. Ведение базы данных с полной информацией о студентах
(ФИО, адрес, телефон, связь с родителями, условия поступления
и т.п.) и поиск по ней. Необходимо также продумать возмож-
ность автоматического изменения номера группы.
2, Распечатка ведомостей на каждый зачет и экзамен по груп-
пам с учетом учебного плана (для чего также придется учесть
преподавателей, ведущих предметы).
3. Поиск задолжников по определенным предметам и по ре-
зультатам сессии, кандидатов на отчисление.
4. Поиск кандидатов на стипендию (успешно сдавших сес-
сию).
5. Оформление вкладышей для дипломов.
Дополнительные задания:
1. В конце 4-го курса вычислить претендентов на красный
диплом.
2. Распределить стипендии успевающим студентам с учетом
успеваемости и курса.
№ 12 «Электронная форма учебника-задачника»
Учебник состоит из нескольких разделов, каждый из которых
содержит несколько тем или параграфов. (Рекомендуется взять
какой-нибудь конкретный учебник по одному из изучаемых
предметов, например, по курсам «Базы данных» или «Экономет-
рика»). В конце каждого параграфа или пункта имеется перечень
контрольных вопросов и типовых задач.
Основное задание:
1. Составить список вопросов по вариантам для проведения
коллоквиума по отдельной теме, по нескольким заданным темам,
по всему курсу. Вопросы в соседних вариантах повторяться не
должны; в каждом варианте - не менее 3-5 вопросов.
2. Составить список задач по вариантам для проведения кон-
трольной по отдельной теме, по нескольким заданным темам, по
всему курсу. В соседних вариантах задачи повторяться не долж-
ны; в каждом варианте - не менее 2-3 задач.
3. Составить билеты к экзамену, состоящие из двух теорети-
ческих вопросов и одной задачи. Вопросы и задача должны быть
из разных тем и относительно равномерно распределены по все-
му курсу.
4. Полученные варианты заданий распечатать:
• с текстами задач и вопросов;
• по номерам задач и вопросов из учебника.
Дополнительные задания:
1. В билетах к экзамену и вариантах контрольных работ
учесть сложность вопросов и задач.
2. В контрольные работы добавить более сложные задачи (со
звездочкой).
3. Составить контрольные работы и тесты с различным коли-
чеством вопросов и задач на определенную сумму баллов.
№ 13 «Работа с недвижимостью»
Крупная риэлтерская фирма ведет учет продаваемой, поку-
паемой, обмениваемой недвижимости. При этом они работают
как с типовыми квартирами, так и с элитным жильем, частным
сектором, нежилыми строениями.
Необходимо продумать модели данных для хранения инфор-
мации о жилье с учетом особенностей указанных видов недви-
жимости. Например, для типового жилья следует учитывать сле-
дующие факторы: район (административные районы рекоменду-
ется разбить на несколько зон с учетом их престижности), тип и
этажность дома, период и планировку застройки, количество жи-
лых комнат, их изолированность, общая и жилая площадь, пло-
щадь кухни, этаж, наличие лифта и мусоропровода, балкона,
лоджии и телефона, пол и высота потолка и др. При этом следует
предусмотреть возможность введения неформальной информа-
ции типа «окна на юг», «экологически чистый район» и т.п. Обя-
зательно должна учитываться стоимость покупки или сдачи не-
движимости внаём как в рублях, так и в твердой валюте.
Основное задание:
1. Осуществлять поиск недвижимости в базе с учетом требо-
ваний клиента.
2. Находить жилье в пределах заданной стоимости, при этом
следует учесть и оплату услуг фирмы.
3. Вести «статистику» наиболее продаваемого (сдаваемого)
жилья.
Дополнительные задания:
1. Вести учет прибыли от сделок по видам и отдельным со-
трудникам фирмы.
2. Автоматически находить варианты сложного обмена с доп-
латами и частичным расчетом жильем, гаражами, машинами и т.п.
№ 14 «Приобретение компьютера»
В городе имеется несколько фирм, торгующих комплектую-
щими к компьютерам (не менее 3-х). Комплектующие описыва-
ются наименованием, назначением, фирмой-производителем,
стоимостью, основными характеристиками и т.п. (рекомендуется
взять реальные прайс-листы и на их основании составить базы
данных).
Основное задание:
1. Рассчитать и выбрать самый дешевый (из нескольких
фирм) вариант компьютера заданной конфигурации.
2. Рассчитать и выбрать самый дешевый (из нескольких
фирм) вариант компьютера заданной конфигурации с учетом
производителя комплектующих.
3. Рассчитать и выбрать самый дешевый (из нескольких
фирм) вариант компьютера заданной конфигурации с учетом до-
полнительных устройств (CD-ROM, принтер, сканер, модем и
пр.).
Дополнительные задания:
1. Учесть разницу в курсах конвертации у.е. в рубли по раз-
личным фирмам.
2. Учесть условия доставки и гарантийного обслуживания.
3. Предусмотреть возможность самостоятельной сборки ком-
пьютера посредством покупки комплектующих в разных фирмах
таким образом, чтобы сумма издержек была минимальной.
4. Выбрать оптимальную (с учетом пожеланий клиента) кон-
фигурацию компьютера в пределах заданной суммы и указать
самую подходящую фирму (или несколько фирм и составляю-
щих, которые в них будут приобретаться при условии самостоя-
тельной сборки).
№ 15- 16 «Автоматизация ведения книги продаж»,
«Автоматизация ведения книги покупок»
Необходимо разработать систему автоматизированного веде-
ния книги продаж/книги покупок предприятия за месяц (отчет-
ный период). Для этого необходимо выполнить следующие дей-
ствия:
1. Разработать электронную форму бланка счета-фактуры
(см. Приложение 1), предусмотрев возможность ввода и коррек-
тировки информации в соответствующих позициях.
2. Разработать электронную форму бланка книги продаж
(Приложение 2)/книги покупок (Приложение 3), при этом необ-
ходимо автоматизировать расчет сумм в целом по каждому доку-
менту.
Основное задание:
1. Счет-фактура, выставляемый покупателю, должен распе-
чатываться.
2. При заполнении счетов-фактур информация должна авто-
матически заноситься в книгу продаж / книгу покупок.
3. Программа должна осуществлять простой поиск по назва-
нию покупателя / продавца, по номеру счета-фактуры, по дате
счета, по наименованию товара и т.п.
4. Осуществить поиск конкретного покупателя / поставщика
(по названию или другим данным) с указанием общей суммы
сделок за отчетный период.
5. Выводить информацию по покупателю / поставщику с рас-
шифровкой ассортимента продаваемой / покупаемой продукции.
Дополнительные задания:
1. По аналогии разработать систему одновременного ведения
книги продаж и книги покупок, сопоставляя суммы покупок и
продаж в каждом месяце.
2. Отобразить график (столбиковую диаграмму) сумм поку-
пок и продаж за несколько месяцев отчетного периода, в том
числе и по отдельным продавцам / покупателям.
№ 17 «Автоматизация работы диспетчера
городского такси»
Водители такси работают на своем собственном транспорте,
отдавая службе фиксированный процент от заработанных на ка-
ждой поездке денег. Машины разделяются по классам (эконом-
класс, средний класс, бизнес-класс, элитный класс). Тарифы за
поездки устанавливаются централизованно по формуле: стои-
мость подачи + километры пути * стоимость километра + время
ожидания * стоимость ожидания. Стоимость зависит от класса
машины.
Постоянные клиенты получают скидку (некий фиксирован-
ный процент от стоимости по стандартному тарифу). Клиенту
предлагают стать «постоянным» после определенного числа по-
ездок с его адреса и/или вызванных с его телефона. Он выбирает
себе уникальное кодовое имя, упрощающее в дальнейшем обще-
ние с диспетчером.
В каждый момент времени управление такси обеспечивает
один диспетчер. Диспетчер принимает звонки и назначает заказы
водителям. На нем лежат важные решения, от которых зависит
прибыль такси, степень удовлетворенности клиентов, удовлетво-
ренность водителей:
• определить, звонит постоянный клиент или «обычный»;
• принять или отказаться от заказа;
• назначить машину желаемого класса или предложить кли-
енту другую;
• выбрать машину для осуществления заказа;
• решить, в какой район ехать водителю после выполнения
заказа.
Зарплата диспетчера представляет собой фиксированный ок-
лад + некий процент от заработанных (службой такси) денег во
время его смен.
Для распределения заказов по водителям используется метод
живой очереди: среди машин нужного класса в нужном районе
выбирается первая в очереди. Удовлетворенность водителей дис-
петчерами зависит от «справедливости» в распределении заказов
(равенстве среднего времени ожидания заказа водителями, мини-
мизации случаев, когда водитель вынужден перемещаться из
района в район пустым (выезжая на заказы или возвращаясь)).
Основное задание:
1. Регистрировать водителей, машины, моменты выхода во-
дителей на работу, моменты завершения работы и т.д.
2. Регистрировать время поступления заказа, телефон клиен-
та, адрес для подачи машины, район назначения поездки, время
приезда машины по адресу отправки, момент начала поездки,
момент окончания поездки, стоимость, взятую с пассажира и т.д.
3. Оперативно регистрировать положение (по районам) сво-
бодных и занятых машин, положение водителей в «живой очере-
ди».
4. Выводить статистику (за определенный период: месяц,
квартал, год и т.п.) распределения количества принятых и откло-
ненных заказов (а также среднего времени между заказами) с раз-
бивкой по сетке «район вызова - район назначения» в зависимо-
сти от времени суток (часовых интервалов) и дней недели с це-
лью стратегического планирования ценовой политики такси,
предсказания и минимизации кризисных периодов нехватки ма-
шин, выявления «выгодных» и «невыгодных» маршрутов и т.п.
Дополнительные задания:
1. Рассчитывать прибыль водителей, зарплаты диспетчеров и
доход такси за выбранный период (месяц, квартал, полугодие и
т.д.).
2. На основе статистики оперативно предсказывать время ос-
вобождения занятых машин (для работы с заказами напряженное
время в случае отсутствия свободных машин (то есть пустых
«живых очередях»)).
3. Выводить сравнительную оценку эффективности работы
разных диспетчеров.
№18 «Электронный органайзер»
Органайзер предназначен для планирования дел, которые
предстоит выполнить его владельцу. Дела могут иметь различные
характеристики: наличие привязки ко времени или ее отсутствие,
периодичность или непериодичность, круг вовлеченных лиц, ис-
пользуемые ресурсы, важность и т.д.
Основное задание:
1. Обеспечить ввод и хранение информации о делах различ-
ных категорий, а также сопутствующей информации (сведений о
лицах и ресурсах).
2. Выводить информацию о делах на заданный период.
3. Выводить информацию о завершенных и незавершенных
делах.
4. Выводить информацию о степени завершенности дел и на
этой основе формировать новые дела.
Дополнительные задания:
1. Выводить оповещения о просроченных и о приближаю-
щихся делах.
2. Выводить статистику об эффективности выполнения дел.
Литература
1. Дейт, К,Дж. Введение в системы баз данных / К.Дж. Дейт;
пер. с англ. - 8-е изд.- М.: Вильямс, 2005. - 1328 с.: ил.
2. Коннолли, Т. Базы данных. Проектирование, реализация и
сопровождение. Теория и практика / Т. Коннолли, К. Бегг; пер. с
англ. - 3-е изд - М.: Вильямс, 2003. - 1440 с.: ил.
3. Крёнке, Д. Теория и практика построения баз данных
/ Д. Крёнке; пер. с англ. - 9-е изд - СПб.г Питер, 2005. - 864 с.,
ил. (Серия «Классика computer science»).
4. Гарсиа-Молина, Г. Системы баз данных. Полный курс
/ Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом; пер. с англ. - М.:
Вильямс, 2003. - 1088 с.: ил.
5. Марков, А.С. Базы данных. Введение в теорию и методо-
логию: учебник / А.С. Марков, К.Ю. Лисовский. - М.: Финансы и
статистика, 2004. - 512 с.: ил,
6. Кузнецов, С.Д. Основы баз данных,: учеб, пособие
/ С.Д. Кузнецов; 2-е изд., испр. - М.: Интернет-университет ин-
формационных технологий; Бином. Лаборатория знаний, 2007. -
484 с.: ил. (Серия «Основы информационных технологий»).
7. Практикум по базам данных: метод, указания / сост.
А.В. Зафиевский, О.Б. Лавровская, Е.М. Спиридонова; Яросл.
гос. ун-т. - Ярославль : ЯрГУ, 2001.
СЧЕТ-ФАКТУРА №
Счет-фактура
от(5) К платежно-расчетному документу №от
Поставщик_____________________________(1)
Адрес_____________________(1 а) тел.___(1 б)
Р/сч.________________(1 в) в___________(1 г)
Город__________________________________(1д)
ИНН поставщика_________________________(1 е)
ОКОНХ(1 ж) ОКПО’1 з)
Покупатель (6)
Адрес (6а) тел. (66)
Р/сч. (6в) в (6г)
Город (6д)
ИНН покупателя (бе)
ОКОНХ (6ж) ОКПО .(6з)
Грузоотправитель и его адрес_____________________________________________________________________________________________(2)
Грузополучатель и его адрес____________________________________________________________________________________________ (3)
Дополнение (7)
(условия оплаты по договору (контракту), способ отправления и т.п.)
Наименование товара Код по ОКДП Ед. изм. Кол-во ' Цена в т.ч. акциз Сумма в т.ч. акциз Ставка НДС Сумма НДС Всего с НДС
1 2 3 4 5 6 7 8 9 10 11
Всего к оплате (8)
Руководитель предприятия Главный бухгалтер
ПОЛУЧИЛ М.П. ВЫДАЛ
(подпись покупателя или уполномоченного (подпись ответственного лица
представителя покупателя) от поставщика)
4>
Книга продаж
Налогоплательщик-продавец: ____________________________________________________________________________
Идентификационный номер налогоплательщика-продавца:
Продажа за период с по
Дата и но- мер счета- фактуры поставщика Наиме- нование покупателя Идентифи- кационный номер покупателя Всего продаж, включая НДС В том числе
Продажи, облагаемые налогом по ставке Продажи, не облагаемые налогом
20% (5) 10% (6) Всего Из них экспорт
Стоимость продаж без НДС Сумма НДС Стоимость продаж без НДС Сумма НДС
(1) (2) (3) (4) (5а) (56) (ба) (66) (7) (7а)
ВСЕГО:
Главный бухгалтер __________________________________
Книга покупок
Налогоплательщик-покупатель: _______________________________________________________________
Идентификационный номер налогоплательщика-покупателя: ______________________________________
Покупки за период с по
Дата и номер счета- фак- туры постав- щика Дата по- ступ- ления счета- фак- туры Дата опла- ты счета- фак- туры Дата опри- ходо- вания то- вара Наиме- нова- ние по- став- щика (про- давца) Иденти- фикаци- онный номер постав- щика (продав- ца) Всего поку- пок, вклю- чая НДС В том числе
Продажи, облагаемые налогом по ставке Продажи, не обл а- гаемые налогом
20% (7) 10% (8)
Стоимость продаж без НДС Сумма НДС Стоимость продаж без НДС Сумма НДС
Всего
(1) (2) (3) (За) (4) (5) (6) (7а) (76) (8а) (86) (9)
ВСЕГО:
Главный бухгалтер ___________________________________
Приложение 4
Пример оформления отчета
В этом приложении приводится пример составления отчета
по одной из реально выполненных работ - задачи о поставке то-
варов в супермаркет. Эта работа, конечно, не является образцом
выполнения, однако на ее примере можно продемонстрировать
основные структурные элементы отчета, а также присущие пред-
ставленному проекту недостатки.
wj» шД* *11^ вДд
«ч
1. Постановка задачи
Целью реализуемого проекта является учет поставки товаров,
поступающих в различные отделы. Товары характеризуются ви-
дом, маркой и ценой, отделы - только наименованием. Для ха-
рактеристики поставщиков используются его наименование, ад-
рес, телефон, а также поставляемая продукция.
Основной функциональной задачей является отбор поставок,
удовлетворяющих одному или нескольким условиям следующего
вида:
• наименование отдела, для которого предназначен товар;
• вид товара;
• марка товара;
• поставка с достаточным количеством товара;
• поставки с ценой товара, не превышающей заданную;
• поставки с минимальной ценой.
2, Требования к системе
Для работы программы требуется компьютер с операционной
системой Windows 98 или Windows ХР, а также запущенный сер-
вер InterBase со стандартной точкой входа (user name=SYSDBA,
password masterkey) Для установки программы достаточно ско-
пировать в одну и ту же папку исполняемый файл BDSU.exe и
файл базы данных marketl.gdb.
3. Входные и выходные документы
Единственным входным документом является накладная на
поставку, с которой вводятся следующие реквизиты:
• наименование поставщика;
• адрес;
• телефон;
• марка товара;
• количество;
• цена единицы товара в рублях.
Наименования отделов, а также перечень видов и поставщи-
ков товаров вводятся без привязки к документам.
Выходные документы не предусмотрены.
4. Выбор СУБД и среды разработки
В качестве системы управления базой данных выбрана СУБД
Borland InterBase 6.0, обладающая простотой, легкостью установ-
ки и использования и достаточной совместимостью со стандар-
том SQL’92.
Для программной разработки использована среда Borland
C++Builder 6, особенностями которой являются нетребователь-
ность к аппаратным ресурсам и широкие возможности исполь-
зуемых разработчиком библиотек.
5. Схема базы данных
Базу данных образуют три таблицы: Section - таблица отде-
лов, Production - таблица видов продукции, Agents - таблица по-
ставок.
Структура этих таблиц следующая.
Section
Имя поля Характеристики Ключ Описание
num integer not null Код отдела
namesection char(25) Название отдела
Production
Имя поля Характеристики Ключ Описание
num integer not null Код строки
name char(20) Вид продукции
dillemame char(25) Поставщик
id integer not null Код отдела
Agents
Имя поля Характеристики Ключ Описание
num integer not null Код строки
name char(25) -It Поставщик
address char(25) Адрес
phone trademark char(15) char(25) Телефон Марка товара
kolvo price idl integer float integer not null — Количество Цена Код строки Produc- tion
id2 integer not null Код отдела
Статические связи таблиц, реализуемые с помощью внешних
ключей, не предусмотрены.
6. Пользовательский интерфейс
При запуске программы открывается основное окно (рис. 1).
При его закрытии программа завершает работу. Кроме того, ра-
бота программы может быть завершена нажатием на кнопку
«Выход» или выбором подпункта «Выход» пункта «Файл» ос-
новного меню.
Файл Правка Попок Сервис Справка
О где п ы супеим я&ке.Т
Продовольственный
Редактировать список отделов...
Вид продукции
Поставщик
► Молоко Молокозавод 4
Молоко Молокозавод 1
_Хлеб Хлебозавод 3
:Хлеб Хлебозавод 6
Хлеб Н.П. Петров
Ветчина Атрус
|₽
Поиск...
Выход...
Информация о поставщиках:
j Поставщик
i ► Молокозавод 4
I Молокозавод 4
Адрес__________
Бол. Октябрьская 45
Бол. Октябрьская 45
Телефон
34-45-56
34-45-56
Марка товара
Молоко 3,2%
Молоко 2,5%
Количество
50
100
Цена р. <*-
5
4
i
?
Рис. 1. Основное окно программы
В основном окне из разворачивающегося списка может быть
выбран отдел, при этом в двух экранных таблицах отображаются
строки таблиц Production и Agents базы данных, соответствую-
щие выбранному отделу. При помещении курсора мыши на одну
из этих таблиц их можно изменять (вставлять, удалять и коррек-
тировать строки) с помощью контекстного меню, а также с по-
мощью пункта «Правка» основного меню. При этом соответст-
вующие изменения вносятся в базу данных.
Изменение списка отделов (вставка и удаление) производится
при нажатии кнопки «Редактировать список отделов» либо при
выборе соответствующего подпункта пункта «Сервис» основного
меню (рис. 2). Изменение наименования отделов не предусмотре-
но.
Основной функционал программы реализован с помощью
окна поиска (рис. 3), которое вызывается нажатием на кнопку
«Поиск...» либо с помощью основного меню.
Пункт «Справка» основного меню содержит только подпункт
«О программе...», при выборе которого выводятся название про-
екта, его версия, дата и место создания, дисциплина, в рамках
которой он разработан, сведения об авторе (фамилия и.о., группа)
и преподавателе.
Название отдела:
П род овоявственный
Мебельный
Бытовая техника
Рис. 2. Окно изменения списка разделов
Отдел:
►
Марке:
500
200
350
560
[Количество ] Цена р. |
57-66-04
56-76-23
{085] 34567-95
12-23-34
7.5
7
3.75
6
Русский
Ярославский
Русский
Борооинжий
Товар
Вид Хлеб
. . йаВИймь____________
| Т е леФон |М арка товара
Поставщик
И. П. Петров
И. 11. Сидоров
Н.П. Петров
ООО Русьхлеб
Адрес
Волокаламское ш д23
Волоколамское ш в. 23
Ямская ул. 56-90
Громова 10
Необходимое количество
Не более: :
Цена
□ Минимальная
Не выше:
Всего выплатить:
24,25' р.
Найти.. [
Выход I
0‘ЫСТИГе
Рис. 3. Окно отбора поставок
7. Программная реализация
Разработка программы велась в стандартной среде Borland
C-H-Builder6 без использования дополнительных библиотек. Ра-
бота с базой данных осуществлялась только с применением языка
SQL. Для доступа к базе данных использовалась технология In-
terBase Express (IBX), наиболее подходящая для работы с СУБД
InterBase.
В качестве примера ниже приводится процедура удаления
строки из таблицы Agents.
void___fastcall TMainForm::MDelClick(TObject *Sender)
{
//I ВТ ransaction->StartT ransaction();
if (Gridflag==1)
{
int k = IBQueryl->FieldByName(’,Num")->Aslnteger;
MessageBeep(MBJCONEXCLAMATION);
if (MessageDIgf’Bbi уверены в вашем решении?”,
mtConfirmation,TMsgDlgButtons() «mbYes« mbNo,0)=-mrYes)
////////////////IBQuery2
IBQuery2->Close();
IBQuery2->SQL->Clear();
IBQuery2->SQL->Add("Delete from agents where (ID1=:PID)”);
IBQuery2->ParamByName("PID")->Aslnteger=k;
IBQuery2->ExecSQL();
I BQuery2->SQL->Clear();
IBQuery2->SQL->Add(”select * from AGENTS where (id1=:Num) and (ID2=:ID)");
I BQuery2->Open();
////////////////IBQueryl
IBQuery1->Close();
I BQuery 1 ->SQL->Clear();
I BQuery 1->SQL->Add(’’Delete from Production where (Num=:PNum)");
IBQuery1->ParamByName(,,PNum’,)->Aslnteger=k;
IBQueryl ->ExecSQL();
IBQuery1->SQL->Clear();
IBQuery 1“>SQL->Add("select * from PRODUCTION where (ID=:Num)’’);
IBQueryl->Open();
/*1 ВТ ransaction->Commit();
for (int i=0;i<MainForm->IBDatabase->DataSetQount;i++)
MainForm->IBDatabase->DataSets[i]->Active=true; */
}
else
{
/*1 ВТ ransaction->Rollback();
for (int i=0;i<MainForm->IBDatabase->DataSetCount;i++)
MainForm->IBDatabase->DataSets[i]->Active=true; */
}
}
if (Gridflag==2)
{
int k = IBQuery2->FieldByName(”Num”)~>Aslnteger;
MessageBeep(MB_ICONEXCLAMATION);
if (MessageDIgf’Bbi уверены в вашем решении?*',
mtConfirmation,TMsgDlgButtons() <<mbYes« mbNo,0)==mrYes)
IBQuery2->Close();
IBQuery2->SQL->Clear();
IBQuery2->SQL->Add("Delete from agents where (Num=:PNum)");
I BQuery2-> Param ByNamef’P N um’')->Asl nteger=k;
I BQuery2->ExecSQL();
IBQuery2->SQL->Clear();
IBQuery2->SQL->Add(”select * from AGENTS where (id1=:Num) and (ID2=:ID)");
I BQuery2->Open();
IBQuery1->Close();
IBQuery1->Open();
/*IBTransaction->Commit();
for (int i=0;i<MainForrn->IBDatabase->DataSetCount;i++)
MainForm->IBDatabase->DataSets[i]->Active=true; */
else
/ЧВТ ransaction->Rollback();
for (int i=0;i<MainForm->IBDatabase->DataSetCount;i++)
MainForm->IBDatabase->DataSets[i]->Active=true; */
8,Тестирование
Методика тестирования, а также тестовые наборы данных не
разрабатывались,
яД^ яД» «Дл яДя
Приведем теперь некоторые комментарии к этому отчету, по-
скольку ошибки, имеющиеся в этом проекте, являются достаточ-
но типичными при разработке информационных систем.
1. Достоинством проекта, к сожалению, чуть ли не единст-
венным, является легкость, с которой автор выполняет кодирова-
ние программы. Используется большое количество управляющих
конструкций, свидетельствующих о том, что до написания этого
проекта автор много и с удовольствием создавал интерактивные
программы на языке C++. Оборотной стороной этого увлечения
является практически полное отсутствие комментариев в текстах
программ, что гарантирует безусловные проблемы при модифи-
кации программы спустя совсем небольшое время. Неуважением
к преподавателю, принимающему проект, является сохранение в
текстах закомментированных кусков программы, не вошедших в
окончательный вариант.
2. Наиболее серьезным недостатком проекта является совер-
шенно недостаточная проработка предметной области проекта
даже в рамках той простой задачи, которая заявлена к реализа-
ции. Очевидно, что основными информационными объектами в
проекте являются:
• отделы;
• виды товаров;
• товары;
• поставщики;
• поставки.
Соответственно этому схема базы данных должна содержать
пять таблиц, каждая из которых содержит информацию, относя-
щуюся к этим объектам. Кроме того, между таблицами имеются
связи по типу «родительская-дочерняя»: вид товара определяет
отдел, в который он будет направлен, поэтому таблица отделов
является родительской по отношению к таблице видов товаров. В
свою очередь, таблица видов товаров является родительской по
отношению к таблице товаров, а таблицы поставщиков и товаров
- родительскими по отношению к таблице поставок. Соответст-
вующая диаграмма схемы базы данных (подготовленная в систе-
ме Microsoft Access) представлена на рис. 4. Жирным шрифтом
выделены ключевые поля. Связи между таблицами изображены
соединительными линиями с пометками «1» у родительской таб-
лицы и «оо» у дочерней.
В представленном же проекте в одной таблице объединяются
несколько сущностей, что приводит к проблемам при определе-
нии первичного ключа, который в таблицах Production и Agents
не имеет содержательного смысла.
Код„посгавшжа
| Код „товара
| Количество
i^^aagrasaera»<Miam^-<a^^atw
р
ж
Адрес
Телефон
Код „поставщика
Наим_поставщика !
у л1Г‘гз-^.^
1
J
vvijsfдй
Код„товара
,Ha«M„TOBaps
Ед_измерения
Цена_ед j
Код „вида
Кодвида
Нсмм„вмда
Код „отдела
Рис. 4. Диаграмма схемы базы данных
Код отдела
3. При проработке предметной области допущены также сле-
дующие ошибки и недочеты:
1)Не проведен анализ функциональной зависимости полей
таблиц. В результате таблица Agents не соответствует требовани-
ям третьей нормальной формы и, как следствие, обладает избы-
точностью и подвержена аномалиям обновления.
2) Не проведено содержательное определение первичного
ключа таблицы поставок. Введенный ключ Num бессодержате-
лен, в то время как естественная комбинация имени поставщика и
марки товара, очевидно, не определяет однозначно строку табли-
цы. Как минимум, в эту таблицу следует добавить поле даты, при
условии, что каждый поставщик осуществляет не более одной
поставки каждого товара в день. В противном случае следует до-
бавить, например, номер накладной.
3) При описании товаров пропущено поле «Единица измере-
ния». Это приводит к таким казусам, как строка «Всего выпла-
тить» в нижней части рис. 3, в которой могут суммироваться це-
ны за лоток хлеба, ящик пива и DVD-плеер.
4) Не проведен анализ документооборота, на основе которого
строится информационная система. Соответственно при вводе
входной информации нарушается принцип «один документ - од-
на экранная форма», придерживаться которого весьма желатель-
но. Отсутствуют выходные документы, выводимые на принтер,
что не позволяет документировать функционирование информа-
ционной системы.
5) Не продуман набор функциональных задач. Вряд ли ра-
зумным является запрос «найти поставку минимальной стоимо-
сти по отделу». В то же время отсутствуют запросы итогового
типа, являющиеся основными в подобного рода системах.
4. При описании типов полей нецелесообразно присваивать
числовые типы полям, с которыми не производится числовых
действий. Это, в частности, относится к полям Num и Id. Пра-
вильнее присваивать им тип char(n). В то же время наименовани-
ям лучше присваивать тип varchar(n) с переменной длиной стро-
ки. Приведенные в проекте размеры строк явно недостаточны:
адрес вполне может занимать 100 знаков и более. Наконец, полю
«Цена» лучше присваивать денежный тип, а при его отсутствии
(как в InterBase) - десятичный тип с двумя знаками после запя-
той.
5. Отсутствует описание статических связей между таблица-
ми, что может приводить (и приводит в данном проекте) к нару-
шению целостности данных. Так, при добавлении товара «Булка»
он попадает в ту группу, к которой относится товар, являвшийся
текущим перед добавлением, например, в «Молоко». Отсутствие
статических связей можно было бы заменить динамическим про-
граммным контролем вводимых данных, однако это не было сде-
лано и, учитывая отсутствие комментариев в программе, этот
контроль был бы забыт или исправлен с ошибками при первой же
модификации программы.
6. Интерфейс программы, как уже отмечалось, можно считать
приемлемым. К числу замечаний можно отнести следующие:
1) Разностильно выполнено управление данными (вставка,
удаление и замена) в таблицах: для таблиц Production и Agents -
через контекстное меню и пункт «Правка» основного меню, а для
таблицы Section - через кнопку «Редактировать список отделов»
и пункт «Сервис» основного меню. Это, впрочем, связано с от-
сутствием привязки экранных форм к документам. Кроме того,
отсутствует возможность переименовать отдел.
2) При выполнения операции поиска информация о виде и
марке товара вводится в поле редактирования, а не выбирается из
списка, что вполне может приводить к результатам, отличаю-
щимся от желаемых. Ситуация дополнительно усугубляется тем,
что поиск выполнен регистровозависимым и, следовательно,
«Хлеб» и «хлеб» - это разные виды товаров.
3) Отсутствует настройка программы на условно-постоянную
информацию, например, на название магазина, банковские рекви-
зиты, праздничные дни и др.
7. Наконец, серьезным недочетом является отсутствие ком-
плексного тестирования системы. Не разработаны методика тес-
тирования, проверяемые функции, контрольные данные и ожи-
даемые результаты, не определены временные характеристики
при больших объемах данных. Работа программы проверялась на
случайных данных, получаемые результаты не анализировались.
В частности, не было замечено нарушение целостности данных
при добавлении и удалении строк.
Таким образом, данный проект вряд ли можно считать ус-
пешным, особенно в части проектирования схемы базы данных.
Только при устранении перечисленных ошибок его можно пред-
ставлять заказчику в качестве демонстрационной версии.
Оглпиление
Предисловие............................................................................в...З
1. Основные понятия...................................................................... 3
1.1. Что такое база данных ................. .. ........................................................3
1.2. Реляционная модель данных........................................................................5
1.3. Связанные таблицы.. ....... ..................................................... 7
/.< Нормализация базы данных.........................................................................9
2. Общая схема процесса проектирования....................................................13
2.1. Общая схема.........................................................................13
2.2. Требования к системе и перечень задач.........................................14
2.3. Входные и выходные документы...................................................... 14
2.4. Пользовательский интерфейс....................................................... 14
2.5. Выбор СУБД и разработка структуры данных.....................................15
2.6. Описание алгоритмов и кодирование.................................................. 16
2.7. Тестирование системы.............................................................................. 17
2.8. Отчет о лабораторной работе..................................................... ...17
3. Варианты заданий для самостоятельной работы...........................................17
Литература....................................... .................................. ...32
Приложение 1. Счет-фактура....................................................... .......33
Приложение 2. Книга продаж ...............................................................34
Приложение 3. Книга покупок.................................................................35
Приложение 4. Пример оформления отчета....................................................36