Содержание
Описание деятельности:
Военнослужащие — лица, состоящие на действительной военной службе, проходят службу в различных воинских частях. Необходимо вести учет как личных данных служащих: ФИО, даты рождения и т.д., так и их воинских знаний, рангов и должностей. Каждому военнослужащему присваивается воинское звание, должность. Военнослужащий закрепляется за местом службы (военная часть). Порядок установления звания военнослужащего, присвоения и лишения их, а также права и обязанности, связанные с различными званиями, определяются законодательными и другими нормативными актами. Список званий и должностей фиксирован и меняется только при изменении законодательства.
Функции предполагаемых пользователей системы:
ФункцияЧастота исполнения
Регистрация нового военнослужащегоПо мере поступления
Увольнение военнослужащегоПо мере надобности
Запись должностей, званий, видов сложностей и удаленностейЕдиноразово
Корректировка должностей, званий, видов сложностей и удаленностейПри необходимости
Повышение надбавки за званиеПри необходимости
Сведение информации по определенной частиПри необходимости
Печать отчёта о военнослужащихЕжемесячно
Печать отчёта о должностях и званияхПри необходимости
Цель проекта: автоматизация учета военнослужащих в частях.
Точки зрения: оператор, ведущий учет военнослужащих.
Входные документы и сообщения:
Данные о частях:
часть A7224;
секретность сверхсекретно;
род войск запаса;
количество военнослужащих 65;
расположение Военный проспект, 4.
Личная карточка военнослужащего:
индивидуальный код военнообязанного AC568974;
ФИО Букин В.Г.;
год рождения 1971;
должность замкомбат;
стаж 5;
удаленность большая;
сложность средняя;
звание капитан.
Перечень должностей:
должность замкомбат;
оклад 3500.
Перечень званий:
звание капитан;
ранг 4;
надбавка за звание 3500.
Перечень сложностей:
сложность сложная;
надбавка за сложность 400.
Перечень видов удаленности:
удаленность большая;
надбавка за удаленность 35.
Выходные документы и сообщения:
Отчет обо всех военнослужащих.
Сводка всех званий и должностей.
Содержание:
ВведениеСтр.6
1. Создание концептуальной моделиСтр.7
2. Создание логической моделиСтр.10
3. Построение структуры базы данныхСтр.12
4. Создание запросов с помощью построителя запросов в среде MS Access и SQL — запросовСтр.14
5. Работа c формамиСтр.16
6. Работа с отчетамиСтр.17
ЗаключениеСтр.18
Список литературыСтр.19
Приложения
Приложение I Приложение XXVIIСтр.20-32
Выдержка из текста работы
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными [1].
Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого [2].
Нередко данные и интерпретация разделены. Например, вышеуказанное утверждение может быть представлено в виде таблицы, в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными.
Применение ЭВМ для введения и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не «знает», является ли «12» количеством месяцев или годовой ставкой (%))[21].
Существует по крайней мере две исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке — основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая «знала», например, что шестое вводимое значение связано с годовой ставкой (%), а седьмое — с количеством месяцев. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве [4].
Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими.
Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых «Системы управления базами данных» (СУБД). Основная особенность СУБД — это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали, называть банки данных, а затем «Базы данных» (БД). Для использования огромных объемов хранимой информации, помимо развития системных устройств, средств передачи данных, памяти необходимы средства обеспечения диалога человек-ЭВМ, которые позволяют пользователю вводить запросы, читать файлы, модифицировать хранимые данные, добавлять новые данные или принимать решения на основании хранимых данных. Эти операции так же обеспечивают системы управления базами данных (СУБД). Современные СУБД — многопользовательские системы управления базой данных, которые специализируется на управлении массивом информации одним или множеством одновременно работающих пользователей.
Существует хорошо известное, но трудно реализуемое на практике понятие базы данных как большого по объему хранилища, в которое организация помещает все необходимые ей данные и из которого различные пользователи могут эти данные получать. Устройства памяти, в которых хранятся все данные, могут быть расположены в одном или нескольких местах; в последнем случае они должны быть связаны средствами передачи данных. К данным должны иметь доступ программы.
Действительно, большинство существующих на сегодняшний день баз данных предназначено для ограниченного ряда приложений. Часто на одной ЭВМ создается несколько баз данных. Со временем базы данных, предназначенные для реализации отдельных родственных функций, можно будет объединить, если такое объединение будет способствовать увеличению эффективности и интенсивности использования всей системы. Если не использовать базы данных, то при обработке большого количества информации появится так много избыточных данных, что фактически станет невозможным сохранять их все на одном и том же уровне обновления. Очень часто пользователи обнаруживают явные противоречия в данных и поэтому испытывают недоверие к полученной от ЭВМ информации. Невозможность хранения избыточных данных на одинаковом уровне обновления является основным препятствием в обработке данных с помощью ЭВМ [6].
Одной из наиболее важных характеристик большинства баз данных является их постоянное изменение и расширение. По мере добавления новых типов данных или при появлении новых приложений должна быть обеспечена возможность быстрого изменения структуры базы данных. Реорганизация базы данных должна осуществляться по возможности без перезаписи прикладных программ и в целом вызывать минимальное количество преобразований. Простота изменения базы данных может оказать большое влияние на развитие приложений баз данных в управлении производством[1].
Актуальность данной темы возрастает. Использование средств вычислительной техники в автоматизированных информационных системах увеличивается. В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д [13].
Целью данной дипломной работы является создание и ведение базы данных для автоматизации управления в конкретной предметной области, в качестве которой была взята «Учет основных средств учреждения».
1 Проектирование базы данных
1.1 Основные этапы проектирования базы данных
Рассмотрим основные этапы проектирования БД [3] :
1. Первый шаг состоит в определении информационных потребностей базы данных. Он включает в себя опрос будущих пользователей для того, чтобы понять и документировать их требования. Следует выяснить следующие вопросы [27]:
какие данные используются разными приложениями; смогут ли приложения совместно использовать какие-либо из этих данных;
кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;
достаточно ли будет для предметной области одной базы или потребуется несколько баз данных с различными структурами;
какая информация является наиболее чувствительной к скорости ее извлечения и изменения.
2. Следующий шаг включает в себя анализ объектов реального мира, которые необходимо смоделировать в базе данных.
Формирование концептуальной модели базы данных включает в себя:
идентификацию функциональной деятельности предметной области.
идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут идентифицировать все сущности и взаимосвязи между ними. Например, процесс «Снятие с учёта» идентифицирует такие сущности как инвентарный номер и идентификационный код пользователя [15].
идентификацию характеристик этих сущностей. Например, сущность учетная запись может включать такие характеристики как Идентификатор пользователя, Ф.И.О., должность, логин, пароль.
идентификацию взаимосвязей между сущностями. Пользователь может иметь далеко не одну единицу под своей ответственностью, в то время как у одной единицы может быть только один ответственный в данный момент.
В результате анализа предметной области было решено использовать одну БД «things», содержащую в себе пять таблиц: таблицы манипуляций; заказов на передачу; пользователей; единиц; типов единиц [8]. Это позволит создать универсальную оболочку, что впоследствии расширит круг применений.
. В первую очередь возникает необходимость формирования базы данных пользователей (потенциально ответственных).
Для создания БД воспользуемся программным средством MySQL 5.0. В таблице, где будут храниться данные о пользователях, необходимо определить соответствующие каждому объекту поля [Приложение Б].
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.
3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы [23], [25].
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы) [2].
Полное информационное содержание базы данных представляется в виде явных значений данных и такой метод представления является единственным.
При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками [11].
3. Третий шаг заключается в установлении соответствия между сущностями и характеристиками предметной области и отношениями и атрибутами в нотации выбранной СУБД. В качестве СУБД было решено использовать СУБД реляционного типа, как наиболее распространенную и доступную. Поскольку каждая сущность реального мира обладает некими характеристиками, в совокупности образующими полную картину ее проявления, можно поставить им в соответствие набор отношений (таблиц) и их атрибутов (полей).
Перечислив все отношения и их атрибуты, уже на этом этапе можно начать устранять излишние позиции. Каждый атрибут должен появляться только один раз; и должны решить, какое отношение будет являться владельцем какого набора атрибутов [29], [31].
4. На четвертом шаге определяются атрибуты, которые уникальным образом идентифицируют каждый объект. Это необходимо для того, чтобы система могла получить любую единичную строку таблицы. Разработчик должен определить первичный ключ для каждого из отношений. Если нет возможности идентифицировать кортеж с помощью одного атрибута, то первичный ключ нужно сделать составным — из нескольких атрибутов. Хорошим примером может быть первичный ключ в таблице работников, состоящий из фамилии, имени и отчества. Первичный ключ гарантирует, что в таблице не будет содержаться двух одинаковых строк. Во многих СУБД имеется возможность помимо первичного определять еще ряд уникальных ключей. Отличие уникального ключа от первичного состоит в том, что уникальный ключ не является главным идентифицирующим фактором записи и на него не может ссылаться внешний ключ другой таблицы. Его главная задача — гарантировать уникальность значения поля [22].
5. Пятый шаг предполагает выработку правил, которые будут устанавливать и поддерживать целостность данных. Будучи определенными, такие правила в клиент — серверных СУБД поддерживаются автоматически — сервером баз данных; в локальных же СУБД их поддержание приходится возлагать на пользовательское приложение.
Эти правила включают:
определение типа данных;
выбор набора символов, соответствующего данной стране;
создание полей, опирающихся на домены;
установка значений по умолчанию;
определение ограничений целостности;
определение проверочных условий.
6. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами) и производится очень важная операция для исключения избыточности данных — нормализация таблиц.
Каждый из различных типов связей должен быть смоделирован в базе данных. Существует несколько типов связей [35]:
связь «один-к-одному»;
связь «один-ко-многим»;
связь «многие-ко-многим».
Связь «один-к-одному» представляет собой простейший вид связи данных, когда первичный ключ таблицы является в то же время внешним ключом, ссылающимся на первичный ключ другой таблицы. Такую связь бывает удобно устанавливать тогда, когда невыгодно держать разные по размеру (или по другим критериям) данные в одной таблице. Например, можно выделить данные с подробным описанием изделия в отдельную таблицу с установлением связи «один-к-одному» для того чтобы не занимать оперативную память, если эти данные используются сравнительно редко [34].
Связь «один-ко-многим» в большинстве случаев отражает реальную взаимосвязь сущностей в предметной области. Она реализуется уже описанной парой «внешний ключ — первичный ключ», т.е. когда определен внешний ключ, ссылающийся на первичный ключ другой таблицы. Именно эта связь описывает широко распространенный механизм классификаторов. Имеется справочная таблица, содержащая названия, имена и т.п. и некие коды, причем, первичным ключом является код. В таблице, собирающей информацию — назовем ее информационной таблицей — определяется внешний ключ, ссылающийся на первичный ключ классификатора. После этого в нее заносится не название из классификатора, а код. Такая система становится устойчивой от изменения названия в классификаторах. Имеются способы быстрой «подмены» в отображаемой таблице кодов на их названия как на уровне сервера БД (для клиент — серверных СУБД), так и на уровне пользовательского приложения. Но об этом — в дальнейших уроках [24].
Связь «многие — ко — многим» в явном виде в реляционных базах данных не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной таблицы, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух таблиц. Итак, после определения таблиц, полей, индексов и связей между таблицами следует посмотреть на проектируемую базу данных в целом и проанализировать ее, используя правила нормализации, с целью устранения логических ошибок. Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные «по природе». Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений [28].
После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:
данные легко обновлять или удалять;
исключается возможность рассоглас……..
Список используемых источников
1. Атре Ш. Структурный подход к организации баз данных. — М.: Финансы и статистика, 1983. — 320 с.
2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. — М.: Финансы и статистика, 1989. — 351 с.
3. Васкевич Д. Стратегии Клиент/Сервер. Руководство специалистам по выживанию для специалистов по реорганизации бизнеса. Пер. с англ. — К.: Диалектика, 1996.
4. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с СУБД. — СПб.: Питер, 1997.
5. Гофман В.Э., Хомоненко А.Д. Delphi 7. Наиболее полное руководство — СПб.: БХВ — Петербург, 2003 — 1216 с.
6. Гофман В.Э., Хомоненко А.Д. Delphi 6. — СПб.: БХВ — Петербург, 2002. -911 с.
7. Гофман В.Э., Хомоненко А.Д. Delphi. быстрый старт.- БХВ — Петербург, 2003. -250 с.
8. Гилула М.М. Множественная модель данных в информационных системах.-М.: Наука, 1992.
9. Дарахвелидзе П., Марков Е. Программирование в Delphi 7.- СПб.: Питер, 2003. — 600 с.
10. Дейт К. Руководство по реляционной СУБД DB2. — М.: Финансы и статистика, 1988. — 320 с.
11. Дейт К. Введение в системы баз данных. — М., СПб., 2000. — 115 с.
12. Диго С.М. Проектирование и использования баз данных. М.: Финансы и статистика, 1995.-369 с.
13. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. — 252 с.
14. Кириллов В.В. Структурированный язык запросов (SQL). — СПб.: ИТМО, 1994. — 80 с.
15. Кнут Д. Искусство программирования для ЭВМ. Т. 1. Основные алгоритмы.-М.: Мир, 1976.
16. Кузнецов С.Д. Введение в СУБД / СУБД. — 1995. — №№ 1-4, 1996.-№№ 1-4, 1997. -№№ 1,2.
17. Ладыженский Г.М. Системы управления базами данных-коротко о главном / СУБД. — 1995. -№№ 1-4.
18. Гилула М.М. Множественная модель данных в информационных системах.-М.: Наука, 1992.
19. Мартин Дж. Планирование развития автоматизированных систем. — М.: Финансы и статистика, 1984. — 196 с.
20. Mеcapoвич М., Такахара Я. Общая теория систем: математические основы.-М.: Мир, 1978.
21. Мейер М. Теория реляционных баз данных. — М.: Мир, 1987. — 608 с.
22. Овчаров Л.А., Селетков С.Н. Автоматизированные банки данных. — М.: Финансы и статистика, 1982.
23. Оспищева Д. А Paradox for Windows: Практическое руководство. АОЗ.: Алевар, 1993.-468 с.
24. Ревунков Г. И.,. Самохвалов Э.Н, Чистов В.В.; Под ред. Четверикова В.Н. М: Высшая школа, 1992
25. Саймон А.Р. Стратегические технологии баз данных. Пер. с англ. — М.: Финансы и статистика, 1998.
26. Тельман Дж. Основы систем баз данных.- М.: Финансы и статистика, 1983. — 316 с.
27. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., — М.: Мир, 1985. Кн. 1. — 287 с.: Кн. 2. — 320 с.
28. Трофимова И.П. Системы обработки и хранения информации: Учеб. пособ. Для вузов по спец. «Автоматизированные системы обработки информ. и управл.».-М.: Высшая школа, 1989.
29. Ульман Дж. Базы данных на Паскале. — М.: Машиностроение, 1990. — 386 с.
30. Хаббард Дж. Автоматизированное проектирование баз данных. — М.: Мир, 1984. — 294 с.
31. Шумаков П. В. Delphi 3.0 и создание баз данных. — М.: Мир, 1997.- 593 с.
32. Фаронов В.В. Система программирования Delphi. — СПб.: БХВ — Петербург, 2004. -736 с.
33. Цаленко М. Ш. Моделирование семантики в базах данных. — М.: Наука,1989.
34. Цикритизис Д., Лоховски Ф. Модели данных. — М.: Финансы и статистика, 1985. — 344 с.
35. Веллинг Л., Томсон Л. Разработка Web-приложений с помощью PHP и
MySQL. Индианаполис, Developer’s Library. 2005.
