Базы данных. Практикум
.pdf
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
№ 43
Кафедра автоматизации систем управления
Е.А. Морозов
Базы данных
Практикум
Рекомендовано редакционно-издательским советом университета
Москва Издательский Дом МИСиС 2009
УДК 004.6 М80
Р е ц е н з е н т д-р техн. наук, проф. В.В. Куприянов
Морозов Е.А.
М80 Базы данных: Практикум. – М.: Изд. Дом МИСиС, 2009. – 83 с.
Анализируются все стадии проектирования приложений базы данных на примере разработки информационной системы для торговой фирмы. Даются практические рекомендации по решению типовых задач, возникающих при проектировании.
Практикум ориентирован на студентов, обучающихся по специальностям 080800 «Прикладная информатика в экономике» и 230102 «Автоматизиро- ванные системы обработки информации и управления». Может быть исполь- зован при выполнении курсовых и дипломных работ.
♥Государственный технологический университет «Московский институт стали и сплавов» (МИСиС), 2009
|
ОГЛАВЛЕНИЕ |
|
Введение.................................................................................................... |
4 |
|
1. |
Порядок разработки приложений ....................................................... |
6 |
2. |
Анализ предметной области и постановка задачи........................... |
10 |
|
2.1. Описание технологического процесса....................................... |
10 |
|
2.2. Первичный анализ технологического процесса ....................... |
13 |
|
2.4. Оценка эффективности автоматизации технологического |
|
|
процесса............................................................................................... |
24 |
|
2.5. Постановка задачи....................................................................... |
25 |
3. |
Разработка структуры базы данных.................................................. |
28 |
|
3.1. Концептуальная схема базы данных.......................................... |
28 |
|
3.2. Логическая схема базы данных.................................................. |
35 |
4. |
Разработка запросов ........................................................................... |
38 |
|
4.1. Задание связей.............................................................................. |
38 |
|
4.2. Базовые примеры запросов......................................................... |
41 |
|
4.3. Итоговые запросы........................................................................ |
44 |
|
4.4. Перекрестные запросы ................................................................ |
52 |
5. |
Разработка форм ................................................................................. |
57 |
|
5.1. Доступ к бланкам свойств........................................................... |
57 |
|
5.2. Свойства данных.......................................................................... |
58 |
|
5.3. Списки и поля со списками ........................................................ |
59 |
|
5.4. Иерархические формы ................................................................ |
63 |
6. |
Разработка отчетов ............................................................................. |
65 |
|
6.1. Сходства и различия отчетов с формами и запросами............. |
65 |
|
6.2. Группировка записей................................................................... |
66 |
|
6.3. Макетирование отчетов .............................................................. |
71 |
7. |
Реализация управления приложением.............................................. |
73 |
Заключение.............................................................................................. |
76 |
|
Задания для самопроверки..................................................................... |
77 |
|
Библиографический список................................................................... |
82 |
|
3
ВВЕДЕНИЕ
За годы существования концепции баз данных (примерно 35–37 лет) в мире создано огромное количество баз данных и их приложений, посвященных самым разным аспектам человеческой деятельности. Однако в обозримом будущем конца этим разработкам не видно. Это естественно, если учесть стремительность развития науки, техники и изменение мирового сообщества в целом. Поэтому разработка новых баз данных и их приложений является постоянно новой, и в то же время и старой задачей.
Первый вопрос, который в связи с этим возникает – нельзя ли обойтись без разработки хотя бы типовых (стандартных) приложе- ний. Попросту говоря, не лучше ли внедрять (адаптировать) старые разработки. Например, задачи по учету кадров, расчету заработной платы, учету материальных средств и т.д. отработаны давным-давно
вогромном количестве автоматизированных систем. И тем не менее, чуть ли не каждое предприятие из года в год разрабатывает и разра- батывает приложения для решения этих задач.
Таким образом, отвечая на вопрос о возможности применения (внедрения) готовых типовых компьютерных систем, следует отве- тить и «да» и «нет». Да, теоретически стандартизация возможна (и очень желательна). Однако на практике она крайне трудно осущест- вима. Почему? Потому, что в соответствии с законом Мэрфи, как только после длительного изучения различных вариантов вы избе- рете систему, которая подходит на 99 %, а оставшийся процент по- крывается возможностью настройки, предусмотренной в системе, в первый день эксплуатации вы обнаружите, что для того, чтобы ис- пользовать эту систему, необходимо поменять весь порядок работы на фирме. Далее вы столкнетесь с проблемами сопровождения этой системы разработчиками: в частности, вам будет очень трудно до- биться внимательного отношения к вашим внутренним проблемам. В конечном счете окажется, что экономический и производственный эффект от системы ничтожен, а ее реальная стоимость в разы, а то и
вдесятки раз превышает стоимость покупки.
Может возникнуть вопрос, как тогда объяснить тенденцию повы- шения спроса на тестировщиков. Действительно, в последние годы многие фирмы стали пользоваться услугами не программистов, а тестировщиков, т.е. специалистов, которые только проверяют рабо- тоспособность чужих компьютерных систем и адаптируют (точнее,
4
пытаются адаптировать) их к нуждам фирмы. В большинстве случаев эти специалисты не знают ни программирования, ни теории баз дан- ных, ни основ проектирования информационных систем. Что можно сказать по этому поводу? Как гласит пословица: «Дай бог нашему теляти волка поймати!».
Данный практикум ориентирован на студентов, освоивших курс по базам данных, намеренных самостоятельно заниматься разработ- кой систем с базами данных и не ставящих перед собой цель кое-как отделаться от них, скачав что-то из интернета.
Практикум не содержит никаких фундаментальных теоретических положений. Предполагается, что все используемые понятия и тер- мины читателю известны.
На простом примере деятельности некоторой торговой фирмы (типичный пример для наших дней) рассматривается процесс проек- тирования базы данных и ее приложения. В качестве инструментария для разработки используются диалоговые средства СУБД Access. При этом также предполагается, что эта СУБД известна читателю. Тем не менее, наиболее важные и сложные аспекты ее использования поясняются. Выбор этой СУБД никак не обосновывается. Она явля- ется только инструментарием для отображения процесса проектиро- вания и может быть при необходимости заменена любой другой.
Цель практикума – показать типичный порядок проектирования, его наиболее важные аспекты и возможные подходы к решению ти- повых задач. Практикум может быть полезен студентам при выпол- нении курсовых и дипломных работ.
5
1. ПОРЯДОК РАЗРАБОТКИ ПРИЛОЖЕНИЙ
Прежде всего, поясним само понятие «приложение», поскольку многие авторы в самых различных публикациях трактуют его по- разному. Приложение базы данных – это программа или комплекс программ, использующих базу данных и обеспечивающих автомати- зацию обработки информации из некоторой предметной области. На рис. 1 показаны таблицы базы данных, типичные компоненты при- ложения и связи между ними.
Рис. 1. Таблицы базы данных и типовые компоненты приложения
6
Иногда у лиц, изучающих теорию баз данных, вызывает недоуме- ние отнесение форм, отчетов, запросов, макросов к разряду компо- нентов приложения. Действительно, эти компоненты имеют двойст- венный смысл, так как при своем использовании могут рассматри- ваться как информационные объекты БД. Однако следует учитывать, что создаются они именно программными средствами (редакторами, генераторами или непосредственно прикладными программами), и, таким образом, не противоречат выше сделанному определению.
Порядок разработки приложений баз данных во многом аналоги- чен порядку разработки любого изделия или процесса. Его основные этапы приведены ниже.
I.Первичный анализ предметной области.
II. Постановка задачи.
III. Проектирование приложения.
IV. Создание действующего макета приложения.
V. Пробная эксплуатация приложения пользователями.
VI. Доработка приложения по результатам пробной эксплуатации. VII. Сдача приложения в эксплуатацию и его сопровождение. Поясним содержание работ первых трех этапов. Именно их мы
будем рассматривать в дальнейшем. Смысл остальных в особых комментариях не нуждается.
На этапе Первичного анализа необходимо:
а) составить для себя четкое представление о том производствен- ном (технологическом) процессе или его части, для которого(ой) вы хотите писать прикладную задачу. Для этого необходимо ответить на следующие вопросы.
1.Какие операции выполняются в данном процессе?
2.Какая информация нужна для выполнения каждой опера- ции? Откуда она берется?
3.Какие документы необходимо выпускать, и в каких опе- рациях?
4.Как в процессе выполнения каждой операции ответствен- ный за ее выполнение сотрудник взаимодействует с другими сотрудниками подразделениями или сторонними лицами, уч- реждениями? Какой информацией он с ними обменивается?
5.Какие изменения технологического процесса наиболее вероятны в будущем?
7
б) оценить, насколько эффективен данный технологический про- цесс. С учетом возможностей компьютерных технологий попытаться выработать рекомендации по модификации этого процесса;
в) обсудить свои рекомендации и прогнозы с пользователями и руководством;
г) провести анализ по п. а) с учетом выработанных и согласован- ных в п. в) изменений.
На этапе Постановки задачи необходимо:
а) определить, какие операции из технологического процесса бу- дут выполняться компьютером, какие пользователем вручную, а ка- кие пользователем на компьютере;
б) определить характер и движение информации в системе.
1.Какие элементы информации обязательны для соответст- вующих операций?
2.Какая информация вводится в компьютер оператором вручную?
3.Какую информацию можно использовать из уже сущест- вующих систем?
4.Как формируются данные для выдачи документов?
5.Какие данные выводятся в каждом документе?
6.Что берется непосредственно из входных данных?
7.Что требует обработки (вычислений, сортировки, поиска
ит. п.)?
8.Что создается внутри системы?
в) составить общее представление об интерфейсе пользователя.
1.Какие операции будут доступны пользователю?
2.Как будет организован ввод данных и вывод документов?
3.Какие настройки задачи могут потребоваться при перене- сении на другие компьютеры, постановке задачи на локальную сеть?
На этапе Проектирования приложения необходимо:
а) разработать структуру базы данных (таблицы, связи между ни- ми);
б) разработать запросы к базе данных; в) разработать пользовательский интерфейс (формы для ввода и
просмотра данных, элементы управления – кнопки, меню, панели инструментов).
г) разработать основные выходные документы.
8
Отметим, что на этапе проектирования в большинстве случаев разработке подлежат все основные компоненты приложения, отме- ченные на рис. 1.
Конечно, данный порядок (прежде всего это относится к этапам I– III) несколько идеализирован. Большую часть необходимых данных разработчик получает уже после создания работающего макета и его пробной эксплуатации пользователем.
Не исключено, что, проработав с приложением достаточно дли- тельное время и пристроив к нему множество «мансард» и «сарайчи- ков», вы придете к выводу, что проще сделать его новую версию, чем пытаться пристроить к нему еще что-нибудь. И тем не менее, чем больше вы соберете информации на начальных этапах, тем дольше вы продержитесь на первой версии, да и создать следующую версию будет гораздо проще.
9
2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ
2.1. Описание технологического процесса
Попытаемся поставить конкретную задачу, которую и будем ис- пользовать в дальнейшем изложении.
Рассмотрим небольшую фирму, одним из направлений деятельно- сти которой является мелкооптовая торговля перевязочными мате- риалами, предметами санитарии и гигиены, а также медикаментами.
В дальнейшем будем разрабатывать для нее небольшую торговую систему. Действуем в соответствии с примерным порядком, введен- ным нами в предыдущем разделе.
Начинаем с описания технологического процесса продаж.
К торговому менеджеру обращается клиент, желающий приобре- сти товар. Клиент может обратиться лично, появившись в офисе, или заочно – по телефону, по электронной почте, письмом, и т.д.
Менеджер собирает всю информацию, которая нужна для удов- летворения потребностей клиента, выписки необходимых докумен- тов (счета, накладной, заявки на резервирование товара на складе) и выполнения операций по исполнению заказа клиента, а далее произ- водит эти операции, набор которых зависит в первую очередь от формы оплаты товара, а также от того, лично или заочно обращался клиент.
Ограничимся следующими формами оплаты: А – безналичная предоплата;
Б – оплата наличными непосредственно при получении товара; В – с отсрочкой платежа на определенный срок.
А. Безналичная предоплата.
При заочном обращении менеджер проделывает следующие опе- рации.
А.1. Выписывает в бухгалтерии счет на завозной товар и, при не- обходимости, за услуги по погрузке и доставке товара.
А.2. Отправляет клиенту счет сам или отдает для отправки секре- тарю или курьеру.
А.3. Ожидает оплаты выставленного счета. Здесь возможны 2 ва- рианта.
10