Описание информационных объектов базы данных.

Информационная система управления торгово-закупочным предприятием на базе СУБД MS Access

Учебное пособие

®®®®®®®®®®®®®®®®®®®®

ОГЛАВЛЕНИЕ

Введение. 2

1. Описание информационных объектов базы данных. 3

2.1. Создание таблицы «Кадры». 4

2.2. Конструирование других таблиц БД. 7

Таблицы Клиенты и Поставщики. 7

Таблица Склад. 7

Таблицы Заказы и Заказ-Товар. 8

3. Построение схемы данных. 9

4. Разработка форм базы данных. 10

4.1. Общие сведения о формах базы данных (Приложение). 10

4.2. Создание форм для ввода данных в таблицы "Кадры", "Клиенты", "Поставщики". 10

5. Создание формы «Склад». 11

6. Создание сложной формы «Прием заказов». 14

6.1. Требования к форме "Прием заказов". 14

6.2. Создание запроса и построение главной формы «Прием заказов». 15

6.3. Создание запроса и построение подчиненной формы. 16

6.4. Построение сложной формы "Прием заказов". 18

7. Создание пользовательского интерфейса. 20

ЗАКЛЮЧЕНИЕ.. 23

Приложения. 24

1. Свойство поля Подстановка таблицы БД. 24

2. Поле объекта OLE.. 24

3. Общие сведения о формах базы данных. 24

4. Проектирование запросов базы данных. 26

ЛИТЕРАТУРА.. 28

Введение

Владение полной и достоверной информацией дает возможность принимать правильные управленческие решения. В полной мере это справедливо и для экономической деятельности.

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

Лидерами на рынке СУБД являются реляционные системы, к числу которых относится и Access, продукт компании Microsoft, входящий в пакет Microsoft Office. Каждая новая версия этой СУБД становится лучшим продуктом года в категории так называемых "персональных СУБД". Такие СУБД сочетают в себе функции управления структурами хранения, обеспечения доступа к данным и поддержке их целостности, а также средства визуального программирования. Это, а также простота работы и изучения, обусловило широкое распространение и определило выбор именно этой СУБД для реализации небольших информационных систем.

Однако простота работы и изучения вовсе не означает, что Access может использоваться только в учебных целях. На ее базе можно реализовать информационную систему, работающую в архитектуре "клиент-файловый сервер", а этого вполне достаточно для относительно небольших компаний. Такая система не требует постоянного администрирования, что минимизирует затраты на ее эксплуатацию. Истинно реляционный характер этой СУБД, заключающийся в декларативной поддержке целостности данных, транзакционном управлении, поддержке языка SQL (язык структурированных запросов) для создания структур хранения и манипуляции данными, позволяет относительно просто выполнить "укрупнение" системы до архитектуры клиент/сервер, в которой Access может играть роль клиента, взаимодействующего с сервером баз данных.

В настоящем пособии предлагается практический подход к изучению данной СУБД. Этот подход состоит в создании конкретного приложения для работы с базой данных, начиная с проектирования таблиц и заканчивая разработкой интерфейса. В процессе построения приложения изучается необходимый для этого материал, а также производятся практические действия по построению базы данных с использованием всех основных ее объектов (таблицы, формы, запросы, отчеты, модули, макросы). Применение кодов на языке VBA – Visual Basic for Application - минимально и осуществляется только на конкретных примерах. Поэтому у читателя пособия должно сложиться цельное и ясное представление о назначении СУБД и возможностях данной прикладной программы, которое послужит базой для ее дальнейшего углубленного изучения и достижения при необходимости профессионального уровня подготовленности пользователя.

За рамками пособия остаются основополагающие принципы реляционной теории, вопросы нормализации отношений, основные положения по использованию языка SQL, описание объектно-ориентированных технологий.

Описание информационных объектов базы данных.

Реляционная модель данных предполагает, что данные представлены только одним способом, а именно в виде таблиц (отношений). Каждая строка (запись) в таблице содержит информацию, относящуюся к некоторому конкретному объекту. Эта информация представляет собой набор фактов, при этом в столбце (называемом также атрибутом или полем), содержится конкретный факт. Столбцы имеют заголовки (имена). Значения столбцов должны быть атомарными (значением столбца не может быть таблица или формула) и однородными.

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

Информация в таблицах связана на основе совпадающих значений (ключей) в столбцах разных таблиц.

Фирма, для которой необходимо построить базу данных, занимается торгово-закупочной деятельностью, поэтому в качестве основных информационных объектов (таблиц) базы данных надо выбрать: «Кадры», «Клиенты», «Склад», «Поставщики», «Заказы».

Вся информация о сотрудниках фирмы будет соответствовать таблице «Кадры», в которой находятся следующие данные:

фамилии, имена и отчества сотрудников;

дата рождения, образование и дата поступления на работу;

адрес, паспортные данные;

информация о семейном положении и детях;

данные о том, в каком отделе работает тот или иной сотрудник, какую должность он занимает, какой у него оклад и др.

Примем, что в данной фирме будут работать следующие сотрудники: директор фирмы, финансовый директор (главный бухгалтер), бухгалтер (2 штатные единицы), секретарь, уборщица. Так как фирма - торгово-закупочная, необходим начальник отдела снабжения и торговые агенты (2 штатные единицы). Отвечать за реализацию товаров будет отдел сбыта, который включает начальника отдела сбыта и торговых представителей (3 штатные единицы). Приобретенные товары будут храниться на складе. На складе нужны кладовщики (2 штатные единицы) и водители (2 штатные единицы). Товары надо разгружать и загружать, поэтому предусмотрим 2 грузчиков, а также введем должность начальника административно-хозяйственного отдела.

Таким образом, структура предприятия содержит отделы: администрация (директор и секретарь); бухгалтерия (финансовый директор и бухгалтеры); отдел сбыта (начальник отдела сбыта и торговые представители); отдел снабжения (начальник отдела снабжения и торговые агенты); административно-хозяйственный отдел (начальник отдела, кладовщики, водители, грузчики и уборщица).

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

Для хранения информации о товаре (название, единица измерения, количество) на складе, а также от какого поставщика, по какой накладной и когда поступил этот товар, необходима таблица «Склад».

Чтобы знать, кому мы продаем наш товар, выделим таблицу «Клиенты». Структура информации в ней аналогична структуре таблицы «Поставщики».

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

Определим, как связана информация в таблицах.

Поставщики поставляют на склад различные товары. При этом один поставщик может поставлять многие товары разных наименований. Поэтому связь между таблицами «Поставщики» и «Склад» - «один ко многим».

Клиенты покупают товары, делая заказы. Каждый клиент может сделать много заказов. Связь между информационными объектами «Клиенты» и «Заказы» – «один ко многим».

Заказы клиентов должны обслуживать сотрудники отдела сбыта. При этом один сотрудник обслуживает много заказов. Таким образом, связь между информационными объектами «Кадры» и «Заказы» – «один ко многим».

Делая заказы, клиенты покупают товары. При этом на один заказ они могут купить товары разных наименований. В то же время со склада распродается много товара по различным заказам. Товар одного наименования может быть частями распродан по нескольким заказам. Таким образом, много товаров продается по многим заказам. Связь между информационными объектами «Склад» и «Заказы» - «многие ко многим».

Поскольку в реляционной СУБД нельзя использовать между таблицами связи типа «многие ко многим», вводятся специальные, или вспомогательные таблицы, которые разбивают связь «многие ко многим» на связи «один ко многим» и «многие к одному». В нашем случае с такой целью добавляем таблицу «Заказ-товар», в которой будут содержаться данные о том, в каких заказах какие конкретные товары и в каком количестве проданы.

Структура фирмы, для которой должна быть разработана база данных (т.е. ее информационные объекты – таблицы и связи между ними) показана на рис.1. Здесь же показано содержание полей этих таблиц. Реальная схема данных будет разработана после конструирования всех таблиц (п.3: Построение схемы данных)

Следующий шаг – конструирование базы данных начинается с разработки таблиц.

2. Конструирование таблиц для базы данных

Дата добавления: 2015-10-24