Оглавление
Введение ………………………………………………………………….….3
1. Описание предметной области. Постановка задачи…………….….. 5
2. Выбор средств проектирования. Выбор СУБД……………………....7
3. Построение концептуальной модели предметной области.……......13
4. Проектирование логической структуры базы данных……………..15
5. Выявление перечня ограничений целостности………………………18
6. Организация ввода данных в БД……………………………………….24
7. Получение отчетов………………………………………………………..28
8. Разработка интерфейса…………………………………………………..31
Заключение…………………………………………………………………...33
Список используемых источников…………… ………………………….34
Введение
В истории вычислительной техники можно проследить развитие двух основных областей ее использования. Первая область - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Развитие этой области способствовало интенсификации методов численного решения сложных математических задач, появлению языков программирования, ориентированных на удобную запись численных алгоритмов. Характерной особенностью данной области применения вычислительной техники является наличие сложных алгоритмов обработки, которые применяются к простым по структуре данным, объем которых сравнительно невелик.
Вторая область - это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. Информационная система представляет собой программно-аппаратный комплекс, обеспечивающий выполнение следующих функций:
1. надежное хранение информации в памяти компьютера;
2. выполнение специфических для данного приложения преобразований
3. информации и вычислений;
4. предоставление пользователям удобного и легко осваиваемого интерфейса.
Обычно такие системы имеют дело с большими объемами информации, имеющей достаточно сложную структуру. Классическими примерами информационных систем (ИС) являются банковские системы, автоматизированные системы управления предприятиями (АСУ), системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д.
История развития СУБД насчитывает более 40 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД – система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных - Conference of Data System Languages(CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.
В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э.Ф. Коддом, который является создателем реляционной модели данных. В 1981 он получил за создание реляционной модели и реляционной алгебры престижную премию Тьюринга Американской ассоциации по вычислительной технике.[]
В 1991 году Microsoft выпустила Access, который на несколько лет вытеснил с рынка все остальные СУБД. Частично это произошло благодаря тому, что Access был интегрирован в Microsoft Office, и Microsoft смогла использовать свое влияние на рынке для смещения других продуктов. Правда, Microsoft нужно отдать справедливость: Access — суперпродукт. Он доминирует на рынке, потому что это легкая в использовании и сильная СУБД.
Цель данной курсовой работы - спроектировать и разработать базу данных для фирмы, торгующей компьютерной техникой. Для создания БД «Фирма-посредник» я буду использовать Microsoft Office Access 2003 как наиболее распространенную и простую в использовании СУБД.
1. Описание предметной области. Постановка задачи
Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС.
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия:
1. состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
2. изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
3. ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в компьютерных системах. Так же как требования к компьютерной системе формируются средствами естественного языка, так и информация в компьютерных системах представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году.
Моя база данных разработана для торговой организации, занимающейся продажей бытовой техники. Схема работы очень проста. Поставщик (все данные и контакты находятся в таблице «Поставщики») поставляет товар фирме. Это отображается в таблице «Поставка». Клиент организации (все данные и контакты находятся в таблице «Клиенты») делает заказ на определенный товар. Этот заказ заносится в таблицу «Продажа». Фирма привозит со склада нужное количество и далее осуществляется сама сделка: клиент получает товар, а мы получаем деньги за выполненный заказ. То есть фактически будут использоваться в основном 2 таблицы — на поставку товара и его продажу. Остальные таблицы, формы, запросы базы будут нужны для информационной, правильной, четкой, работы. Чтобы можно было сразу узнать, кто заказал, кто производитель, описание товара, посчитать суммы заказов, сделать отбор по определенным данным, добавить товар, получить отчеты по товарам и клиентам и выйти из базы.
2.Выбор средств/методологии проектирования. Выбор СУБД
В деловой или личной сфере часто приходится работать с данными из разных источников, каждый из которых связан с определенным видом деятельности. Для координации всех этих данных необходимы определенные знания и организационные навыки.
Для реализации базы данных были выбраны СУБД MsAccess и ER-WIN.
Приложение Microsoft Access является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (далее СУБД).
Access - мощное приложение Windows. При этом производительность СУБД органично сочетается со всеми удобствами и преимуществами Windows.
Как реляционная СУБД, Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase. Работая в среде Microsoft Office, пользователь получает в своё распоряжение полностью совместимые с Access текстовые документы (Word), электронные таблицы (Excel), презентации (PowerPoint). С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из World Wide Web и транслировать представление данных на языке HTML, обеспечивая работу с такими приложениями как Internet Explorer и Netscape Navigator.
Access специально спроектирован для создания многопользовательских приложений. В Access реализована надёжная система защиты от несанкционированного доступа к файлам.
База данных храниться в одном файле, но профессиональные пользователи предпочитают разделять базу данных на два файла: в одном хранятся объекты данных (таблицы, запросы), в другом объекты приложения (формы, отчёты, макросы, модули).
В последних версиях Access представлен новый формат файла (.MDE) –библиотеки, с помощью которого можно создавать приложения, не включая VBA - код.
Несмотря на то, что Access является мощной и сложной системой, его использование не сложно для непрофессиональных пользователей.
Microsoft Access объединяет сведения из разных источников в одной
реляционной базе данных. Создаваемые формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, получать ответы на вопросы, осуществлять поиск нужных данных, анализировать данные, печатать отчеты, диаграммы и почтовые наклейки.
В базе данных сведения из каждого источника сохраняются в отдельной таблице. При работе с данными из нескольких таблиц устанавливаются связи между таблицами. Для поиска и отбора данных, удовлетворяющих определенным условиям, создается запрос. Запросы позволяют также обновить или удалить одновременно несколько записей, выполнить встроенные или специальные вычисления. Для просмотра, ввода или изменения данных прямо в таблице применяются формы. Форма позволяет отобрать данные из одной или нескольких таблиц и вывести их на экран, используя стандартный или созданный пользователем макет. Для анализа данных или распечатки их определенным образом используется отчет.
База данных может содержать до 32768 объектов.
В состав Access входит множество мастеров, построителей и надстроек, которые позволяют упростить процесс создания объектов базы данных.
Для моделирования предметной области ИС воспользуемся таким средством как ERwin.
ERwin — современное средство проектирования баз данных
ERwin - мощное и простое в использовании средство конструирования баз данных завоевавшее широкое признание и популярность.
Оно обеспечивает высочайшую продуктивность труда при разработке и сопровождении приложений с использованием баз данных. На протяжении всего процесса - от логического моделирования требований к информации и бизнес-правил, которые определяют базу данных, до оптимизации физической модели в соответствии с заданными характеристиками - ERwin позволяет наглядно отобразить структуру и основные элементы БД.
ERwin - это не просто мощное средство проектирования, но и инструмент разработки, способный автоматически создавать таблицы и генерировать тысячи строк текста хранимых процедур и триггеров для всех популярных СУБД. Революционная технология Complete-Compare (Завершить-Сравнить) позволяет поддерживать постоянную согласованность модели и базы данных.
Благодаря интеграции с популярными средами разработки программ, Erwin позволяет ускорить создание приложений для обработки данных. ERwin может масштабироваться путем интеграции с продуктом PLATINUM ModelMart. Эта мощная система управления моделями позволяет проектировщикам баз данных разработчикам приложений и пользователям коллективно работать с информацией о моделях ERwin. Благодаря возможностям разбиения на фрагменты, а также совместного и многократного использования моделей, может быть повышена эффективность моделирования и обеспечено соблюдение корпоративных стандартов.
ERwin облегчает проектирование баз данных. Для этого достаточно создать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки. Можно расширить возможности Erwin, воспользовавшись уникальной поддержкой пользовательских свойств, для ввода в модель любой дополнительной информации, значимой для деятельности. Развитые средства моделирования помогают лучше спроектировать базу данных. Предусмотрены возможности манипулирования атрибутами путем их буксировки, внесения изменений и нормализации «на лету». Средства редактирования непосредственно на диаграммах позволяют вносить в модель изменения, не открывая специальных диалоговых окон. Навигация по отношениям обеспечивает быстрое перемещение в больших моделях для перехода к родительским или дочерним объектам.
Формируемые системой отчеты позволяют быстро проверить корректность спроектированной базы данных.
ERwin - это не что гораздо большее, чем просто инструмент для «рисования"; он автоматизирует процесс проектирования. Например, ERwin предусматривает возможность создания каталога наиболее часто используемых атрибутов, что обеспечивает согласованность имен и описаний по всему проекту.
Представления БД поддерживаются как интегрированные компоненты модели, что позволяет автоматически отображать в их описаниях изменения, внесенные в базовые таблицы. Автоматический перенос ключей обеспечивает ссылочную целостность базы данных. Кроме того, ERwin позволяет работать с большими моделями общекорпоративного масштаба, разбивая их на фрагменты и легко управляемые подмножества, предоставляя отдельным специалистам возможность сосредоточить свои усилия в определенной области. Возможность сохранения отображений позволяет хранить множество представлений одной предметной области, ориентированных на различную целевую аудиторию. Созданные с помощью ERwin модели данных можно редактировать, просматривать и распечатывать различными способами. В состав ERwin входит RPTwin - простая в использовании, оснащенная графическим интерфейсом утилита для формирования отчетов и встроенное средство для просмотра с настраиваемыми режимами, которые обеспечивают полный контроль над отображением содержимого отчетов. Кроме этого, уникальный интерфейс, построенный на использовании шаблонов, позволяет реализовать единые стандарты проектирования и отображать настройки для всех моделей.
ERwin - не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания. ERwin оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств, ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения многие-ко-многим, в их реализацию на физическом уровне. ERwin устанавливает естественную динамическую связь между моделью и базой данных, что позволяет реализовать как прямой, так и обратный инжиниринг. Используя эту связь, Erwin автоматически генерирует таблицы, представления, индексы, правила поддержания целостности ссылок (первичных и внешних ключей), устанавливает значения по умолчанию и ограничения для доменов/столбцов. В состав Erwin включен целый ряд оптимизированных шаблонов триггеров, обеспечивающих целостность ссылок, и мощный макроязык, который позволяет создавать собственные триггеры и хранимые процедуры. Таким образом могут быть автоматически сформированы тысячи строк кода, что обеспечивает непревзойденную продуктивность разработки на основе моделей.
База данных может быть спроектирована и создана без написания отдельных SQL-предложений типа CREATE TABLE или INDEX. Поскольку физическая схема формируется на основе описательной логической модели, приложение будет сразу же полностью документировано. ERwin позволяет также проводить обратный инжиниринг существующих баз данных путем построения модели непосредственно на основе ее таблиц. Таким образом можно получить четкое представление о структуре и содержании существующего приложения. ERwin поддерживает все наиболее популярные реляционные СУБД, включая Oracle, Microsoft SQL Server, Sybase, DB2 и Informix. Одна и та же модель может быть использована для создания нескольких баз данных или для переноса приложения с платформы одной СУБД на другую.
ERwin интегрирует проектирование базы данных в процесс разработки приложения. Благодаря возможностям взаимодействия с популярными средствами разработки для архитектуры клиент/сервер и Web, ERwin поддерживает соответствие между серверной базой данных и формами в клиентской части, позволяя ускорить создание высококачественных приложений.
3. Построение концептуальной модели предметной области
Концептуальная модель (информационно-логическая модель) — ориентированная на человека и не зависимая от типа СУБД модель предметной области, определяющая совокупности информационных объектов, их атрибутов и отношений между объектами, динамику изменений предметной области, а также характер информационных потребностей пользователей. Концептуальная модель предметной области может быть описана моделью "сущность—связь" (моделью Чена), в основе которой лежит деление реального мира на отдельные различимые сущности, находящиеся в определенных связях друг с другом, причем обе категории — сущность и связь полагаются первичными, неопределенными понятиями.
Цель - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому концептуальную модель данных пытаются строить по аналогии с естественным языком ( последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка).
Требования, предъявляемые к концептуальной модели:
1. Адекватное, отображение предметной области;
2. Недопущение неоднозначной трактовки модели;
3. Четкое определение моделируемой предметной области;
4. Легкая расширяемость, обеспечивающая ввод новых данных без изменения ранее определенных, то же относят и к удалению данных;
5. Возможность композиции и декомпозиции модели в связи с большой размерностью реальных инфологических моделей;
6. Легкое восприятие различными категориями пользователей. Желательно, чтобы концептуальную модель строил (или хотя бы участвовал в ее создании) специалист, работающий в данной предметной области, а не только проектировщик систем машинной обработки данных;
7. Применимость языка спецификаций модели как при ручном, так и при автоматизированном проектировании информационных систем.
На Рисунке 1.изображены связи между сущностями БД «Фирма-посредник».
Рисунок 1.- Связи между сущностями
Таким образом, концептуальная модель является, по существу, моделью предметной области.
4. Проектирование логической структуры базы данных
Основной целью этапа создания логической модели базы данных является преобразование информационной модели предметной области базы данных в логическую модель реляционной базы данных. Создание логической модели базы данных предполагает решение следующих основных задач и выполнения операций в рамках таких задач:
1. нормализация сущностей предметной области:
2. получить список атрибутов сущности;
3. определить функциональные зависимости (ФЗ) в сущности;
4. определить детерминанты сущности;
5. определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности.
6. выполнить нормализацию сущности (преобразовать сущность в отношение);
7. для полученного отношения назначить первичные ключи;
8. сформировать список кандидатов на внешние ключи, если необходимо;
9. сформировать бизнес-правила поддержки целостности сущности, если необходимо;
10. нормализация отношений логической модели базы данных:
11. определить степень связи сущностей;
12. определить класс принадлежности сущности к связи;
13. нормализовать отношение (разрешить связи);
14. назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;
15. определить атрибуты связывающих отношений, если необходимо;
16. сформировать бизнес-правила поддержки целостности связей;
17. проверка правильности логической модели реляционной базы данных:
18. проверка отношений на соответствие нормальной форме Бойса-Кодда;
19. проверка отношений на свойства соединения без потерь и сохранения функциональных
20. предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
21. проверка на отсутствие незамкнутых связей;
22. проверка на отсутствие одиночных отношений;
23. формулировка части исходных данных для решения задачи управления ссылочной целостностью;
24. документирование логической модели реляционной базы данных;
25. принятие решения о реализуемости построенной логической модели реляционной базы данных;
26. принятие решения о разработке физической модели реляционной базы данных.
|
Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отмечу, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например, связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим".
Рисунок 2. - Логическая структура базы данных «Фирма-посредник»
На Рисунке 2. изображена логическая структура базы данных «Фирма-посредник», выполненная в ER-Wine. На ней отображены сущности, их атрибуты и связи между сущностями.
5. Выявление перечня ограничений целостности
Целостность базы данных - соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint).
Задача аналитика и проектировщика базы данных — более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.
Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает, по крайней мере, правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.
Обеспечение целостности БД - важнейшая задача при создании БД, поскольку обеспечение адекватности базы данных отображаемой предметной области является одним из основных требований, предъявляемых к БД.
Существует 3 вида ограничений целостности:
1. Целостность по сущностям;
2. Целостность по ссылкам;
3. Целостность, определяемая пользователем.
Объекту, или сущности реального мира, в БД соответствуют кортежи отношения. Любой кортеж должен быть отличим от любого другого кортежа по составным значениям заранее определенного множества атрибутов, т.е. любое отношение должно обладать первичным ключом.
Первичный ключ представляет собой один из примеров уникальных индексов и применяется для уникальной идентификации записей таблицы. Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа. Первичный ключ обычно сокращенно обозначают как PK (primary key).
В реляционных базах данных практически всегда разные таблицы логически связаны друг с другом. Первичные ключи как раз используются для однозначной организации такой связи.
По способу задания первичных ключей различают логические (естественные) и суррогатные (искусственные).
Для логического задания первичного ключа нужно выбрать в базе данных то, что естественным образом определяет запись. Примером такого ключа является номер паспорта в базе данных о паспортных данных жителей.
Если подходящих примеров для естественного задания первичного ключа не находится, пользуются суррогатным ключом. Суррогатный ключ представляет собой дополнительное поле в базе данных, предназначенное для обеспечения записей первичным ключом.
В БД «Фирма-посредник» я использовала искусственные первичные ключи, так как такой способ их назначения более простой, понятный и не создающий путаницы.
Для сущности «Товар» первичным ключом стало поле «Код товара», «Поставщики» - «Код поставщика», «Клиенты» - «Код клиента», «Продажа» - «Код продажи», «Поставка» - «Код поставки», «Менеджер поставки» - «Код менеджера поставки», «Менеджеры продажи» - «Код менеджера продажи».
Требование целостности по сущности означает, что первичный ключ должен полностью идентифицировать каждую сущность, а поэтому в составе любого значения первичного ключа не допускается наличие неопределенного значения Null.
Для того чтобы обойти проблему неполных или неизвестных данных, в базах данных могут использоваться типы данных, пополненные так называемым null-значением. Null-значение - это, собственно, не значение, а некий маркер, показывающий, что значение неизвестно.
Таким образом, в ситуации, когда возможно появление неизвестных или неполных данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны - не все данные становятся равноправны, требуется дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.
Второй вариант состоит в использовании null-значений вместо неизвестных данных. За кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие проблемы. В этом случае при неаккуратном формулировании запросов, даже самые естественные запросы могут давать неправильные ответы. Есть более фундаментальные проблемы, связанные с теоретическим обоснованием корректности введения null-значений, например, непонятно вообще, входят ли null-значения в домены или нет. Практически все реализации современных реляционных СУБД позволяют использовать null-значения, несмотря на их недостаточную теоретическую обоснованность.
Различные объекты предметной области, информация о которых хранится в БД, всегда взаимосвязаны друг с другом. Такие связи отражаются при помощи внешних ключей, связывающих несколько отношений.
Внешним ключом называется поле таблицы, предназначенное для хранения значения первичного ключа другой таблицы с целью организации связи между этими таблицами.
Подмножество атрибутов отношения называется внешним ключом, если:
1. Существует отношение с потенциальным ключом;
2. Каждое значение в отношении всегда совпадает со значением для некоторого кортежа либо является null-значением.
Замечание 1. Внешний ключ, также как и потенциальный, может быть простым и составным.
Замечание 2. Внешний ключ должен быть определен на тех же доменах, что и соответствующий первичный ключ родительского отношения.
Замечание 3. Внешний ключ, как правило, не обладает свойством уникальности. Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей, ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает тип отношения "один-ко-многим".
Замечание 4. Если внешний ключ все-таки обладает свойством уникальности, то связь между отношениями имеет тип "один-к-одному". Чаще всего такие отношения объединяются в одно отношение, хотя это и не обязательно.
Замечание 5. Хотя каждое значение внешнего ключа обязано совпадать со значениями потенциального ключа в некотором кортеже родительского отношения, то обратное, вообще говоря, неверно. Например, могут существовать поставщики, не поставляющие никаких товаров.
Замечание 6. Для внешнего ключа не требуется, чтобы он был компонентом некоторого потенциального ключа
Замечание 7. Null-значения для атрибутов внешнего ключа допустимы только в том случае, когда атрибуты внешнего ключа не входят в состав никакого потенциального ключа.
Т.к. внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.
Это определяет правило целостности внешних ключей - внешние ключи не должны быть несогласованными, т.е. для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительском отношении.
В Access многие ограничения целостности могут задаваться самим пользователем при создании таблицы.
Тип поля. Он определяет допустимые символы, которые могут быть использованы при его заполнении (в частности, не допускается ввод текста в числовые поля).
Для некоторых типов полей, например, поля типа «дата», осуществляется и более сложная проверка. Если допущена ошибка в типе данных или неправильно введена дата, то пользователь должен обязательно исправить ошибку, так как СУБД не дает других возможностей продолжить работу.
Ряд свойств полей также позволяет обеспечивать контроль целостности:
1. размер поля;
2. формат поля;
3. маска ввода;
4. значение по умолчанию;
5. условия на значения;
6. сообщение об ошибке;
7. обязательное поле;
8. пустые строки;
9. индексированное поле.
Каждое из них в той или иной степени связано с ограничениями целостности.
Существует 3 подхода, поддерживающих целостность:
1. Вообще запрещается производить удаление кортежа, для которого существуют ссылки;
2. При удалении кортежа, на который существуют ссылки, во всех ссылающихся кортежах значения внешнего ключа автоматически становятся полностью неопределенными;
3. При удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи - каскадное удаление.
6. Организация ввода данных в БД
|
Для проектировщика БД удобнее вводить и редактировать данные в режиме «Таблица». Поэтому я создала несколько таблиц, соответствующих сущностям БД.
Рисунок 3. - Таблица «Товары»
Рисунок 4. - Таблица «Клиенты»
|
Рисунок 5. – Таблица «Поставщики»
|
Рисунок 6. - Таблица «Поставки»
|
Рисунок 7. – Таблица «Продажи»
|
Рисунок 8. – Таблица «Менеджеры поставок»
|
Рисунок 9. – Таблица «Менеджеры поставок»
На основе этих таблиц и занесенных в них данных созданы формы. Они предназначены для наглядности информации, хранящейся в БД. Представим основные формы - «Поставка товара» и «Продажа товара».
|
Рисунок 10. – Форма «Поставки»
|
Рисунок 11. – Форма «Продажа»
Как видно на Рисунках 10 и 11, я использовала подчиненную форму.
Подчиненная форма - это форма, которая входит в состав другой формы и отображает данные из связанной таблицы. Благодаря ей мы можем одновременно видеть как данные о поставке, так и о менеджере данной поставки (Рисунок 10).
7. Получение отчетов
Часто при работе с базами данных появляется необходимость создания документов для подведения каких-либо итогов, и, которые, как правило, выводятся на печать. К таким документам в Access относятся отчеты.
Пользователь имеет возможность разработать отчет самостоятельно или создать отчет с помощью мастера. Мастер по разработке отчетов Microsoft Access выполняет всю рутинную работу и позволяет быстро разработать отчет. После вызова мастера выводятся диалоговые окна с приглашением ввести необходимые данные, и отчет создается на основании ответов пользователя. Мастер окажется полезным даже для опытных пользователей, так как позволяет быстро разработать макет, служащий основой создаваемого отчета. После этого можно переключиться в режим конструктора и внести изменения в стандартный макет.
Для моей БД я создала следующие отчеты:
1. Продажа товара (сортировка по коду клиента);
2. Продажа товара;
3. Поставка товара (сортировка по месяцам);
4.
|
Поставка товара.
Рисунок 12. – Отчет о продаже товаров (по коду клиента)
|
Рисунок 13. – Отчет о продаже
|
Рисунок 4. – Отчет о поставках по месяцам
|
Рисунок 15. – Отчет о поставках
Отчеты Access обычно имеет смысл использовать в тех случаях, когда требуется создание отчета на бумажном носителе (по электронной почте, например, удобнее пересылать документы Word). Не следует рассматривать отчет как нечто незыблемое - напротив, любой рабочий отчет должен находиться в состоянии непрерывного улучшения. Усовершенствования, как правило, должны сводиться к визуализации необходимой пользователю информации, приведению ее в наиболее удобный для пользователя вид.
8. Разработка интерфейса
Для управления созданной базой данных необходимо создать полноценное приложение. Между базой данных и приложением существуют два коренных отличия:
1. задачи, которые в базе данных выполняются «вручную», в приложении максимально автоматизированы;
2. для приложения разрабатывается специальный интерфейс, позволяющий сделать обслуживание базы данных максимально удобным для пользователя.
Для грамотного создания приложения необходимо составить список основных задач, которые должно выполнять приложение:
1. ассортимент товаров должен изменяться;
2. каждый менеджер вводит данные о поставке и продаже товаров;
3. список сотрудников может меняться;
4. периодически требуется выводить отчеты о поставках и продажах товаров.
С целью реализации этих задач я создала кнопочную форму, элементы которой представлены на следующих рисунках.
|
Рисунок 16. – Главная кнопочная форма
|
Рисунок 17. – Служебные данные
|
Рисунок 18. – Отчеты по деятельности
В главной кнопочной форме я использовала не таблицы, не запросы, а именно формы. Это связано с тем, что работать с ними удобнее, они более привлекательны по внешнему виду и менее напрягают зрение при работе.
Заключение
По мере того как возрастает значение информации в обществе, столь же быстро растет и роль баз данных. К небольшому числу крупных систем, существовавших несколько лет назад, присоединилось огромное количество более мелких систем (а также новые крупные). Однако сложность развертывания и использования подобных систем не соответствует темпам их распространения.
СУБД следующего поколения должны обладать более совершенными интерфейсами, причем не только для конечного пользователя, но и для прикладного программиста и администратора. Целью здесь нужно считать создание баз данных, столь же простых в использовании, как электронные таблицы, которые часто применяются в качестве рудиментарных систем баз данных.
Целью данной курсовой работы было создание БД. Проделанная работа позволяет любому пользователю с легкостью создавать большие объемы информации, обрабатывать их, сортировать, делать выборки по определенным критериям. Использование такой программы в современном мире значительно облегчает деятельность человека, автоматизируя и ускоряя ее.
Список используемых источников
Учебники, монографии, брошюры
1. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. пособие. – 2-е изд., испр. и доп. – М.: ФОРУМ: ИНФРА-М, 2007.
2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г., Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д. Хомоненко. – 4-е изд., доп. и перераб. – СПб.: КОРОНА принт, 2005.
3. Т.Коннолли, К.Бегг, А.Страчан. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 5-е изд.: пер. с англ. - М.: Издательский дом «Вильямс», 2006.
4. Диго С.М. Проектирование и использование баз данных (учебник). М: Финансы и статистика. 2000.
5. Т.С.Карпова Базы данных: модели, разработка, реализация. СПб. Питер, 2006.
6. Дейт К.Дж. Введение в системы баз данных, 6-е издание. К., М., СПб.: Издательский дом "Вильямс", 2000.
7. Кириллов В.В. Введение в реляционные базы данных / В.В.Кириллов, Г.Ю. Громов. – СПб.: БХВ-Петербург, 2009.
8. льман Дж. Основы систем баз данных. — М.: Финансы и статистика, 1983.
9. Диго С.М.
БАЗЫ ДАННЫХ. ПРОЕКТИРОВАНИЕ И СОЗДАНИЕ: Учебно-методический комплекс. – М.: Изд. центр ЕАОИ. 2008.
10. Диго С.М. Базы данных: Руководство по изучению дисциплины / Московский государственный университет экономики, статистики и информатики – М.: МЭСИ, 2005.
Электронные ресурсы
11. www.citforum.ru
12. www.ituit.ru