Учебная работа. Реферат: Базы данных 6

Учебная работа. Реферат: Базы данных 6

Оглавление

Введение ………………………………………………………………….….3

1. Описание предметной области. Постановка задачки…………….….. 5

2. Выбор средств проектирования. Выбор СУБД……………………….7

3. Построение концептуальной модели предметной области.…………13

4. Проектирование логической структуры базы данных……………..15

5. Выявление списка ограничений целостности………………………18

6. Организация ввода данных в БД……………………………………….24

7. Получение отчетов………………………………………………………..28

8. Разработка интерфейса…………………………………………………..31

Заключение……………………………………………………………………33

Перечень применяемых источников…………… ………………………….34

Введение

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

2-ая область — это внедрение средств вычислительной техники в автоматических либо автоматических информационных системах. Информационная система представляет собой программно-аппаратный комплекс, обеспечивающий выполнение последующих функций:

1. надежное хранение инфы в памяти компа;

2. выполнение специфичных для данного приложения преобразований

3. инфы и вычислений;

4. предоставление юзерам комфортного и просто осваиваемого интерфейса.

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

История развития СУБД насчитывает наиболее 40 лет. В 1968 году была введена в эксплуатацию 1-ая промышленная СУБД – система IMS компании IBM. В 1975 году возник 1-ый эталон ассоциации по языкам систем обработки данных — 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 и передавать работу с таковыми приложениями как 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 интегрирует проектирование базы данных в процесс разработки приложения. Благодаря способностям взаимодействия с пользующимися популярностью средствами разработки для архитектуры клиент/сервер и 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. Целостность, определяемая юзером.

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

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

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

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

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

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

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

Для сути «Продукт» первичным ключом сделалось поле «Код продукта», «Поставщики» — «Код поставщика», «Клиенты» — «Код клиента», «Продажа» — «Код реализации», «Поставка» — «Код поставки», «Менеджер поставки» — «Код менеджера поставки», «Менеджеры реализации» — «Код менеджера реализации».

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

Для того чтоб обойти делему неполных либо неведомых данных, в базах данных могут употребляться типы данных, пополненные так именуемым null-значением. Null-

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

1-ый вариант заключается в том, чтоб ограничиться внедрением обыденных типов данных и не употреблять null-значения, а заместо неведомых данных вводить или нулевые значения, или значения специального вида — к примеру, условиться, что строчка «адресок НЕИЗВЕСТЕН» и есть те данные, которые необходимо вводить заместо неведомого адреса. В любом случае на юзера (либо на разраба) ложится ответственность на правильную трактовку таковых данных. А именно, может потребоваться написание специального программного кода, который в подходящих вариантах «вылавливал» бы такие данные. Трудности, возникающие при всем этом явны — не все данные стают равноправны, требуется доп программный код, «отслеживающий» эту неравноправность, в итоге чего же усложняется разработка и сопровождение приложений.

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

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

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

Подмножество атрибутов дела именуется наружным ключом, если:

1. Существует отношение с возможным ключом;

2. Каждое

Замечание 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

]]>