Проектирование баз данных
Разработка баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами. Создание схемы данных, отчетов, разработка логической структуры. Реализация баз данных для обеспечения учета оргтехники.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 25.10.2009 |
Размер файла | 469,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
СОДЕРЖАНИЕ
Введение
Глава 1 Проектирование баз данных
1.1 Сбор информации о предметной области
1.2 Построение информационно-логической модели данных
1.3 Разработка логической структуры БД
Глава 2 Создание и использование базы данных
2.1 Конструирования структур таблиц
2.2 Создание схемы данных
2.3 Создание запросов и форм
2.4 Создание отчётов
Заключение
Список литературы
Приложения
П 1 Схема данных базы
П 2 Листинг SQL-запросов
Введение
В настоящее время практически во всех сферах человеческой деятельности используются базы данных. В том числе решение перечисленных задач позволит достигнуть цели, поставленной в курсовой работе, а именно, реализовать базу данных для обеспечения учета оргтехники.
Одним из важнейших условий обеспечения эффективного функционирования любой организации является наличие развитой автоматизированной информационной системы (АИС). Под АИС понимают все системы, реализующие автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал. Современной формой АИС являются автоматизированные банки данных (АБД), которые включают в свой состав вычислительную систему, одну или несколько БД, систему управления базами данных (СУБД) и набор прикладных программ (ПП).
Проектирование информационных систем (АБД), включающих в себя базы данных, осуществляется на физическом и логическом уровнях. Решение проблем проектирования на физическом уровне во многом зависит от используемой СУБД, оно зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю предоставляется возможность настройки отдельных параметров системы, что не составляет большой проблемы.
Цель курсовой работы: реализовать базу данных для обеспечения учета оргтехники.
Рассмотрим проектирование БД на примере предметной области «Оргтехника».
Пусть необходимо построить базу данных, содержащую информацию о системе учета сборки изделий:
· перечень поставщиков;
· список служащих;
· сведения о движении товаров.
Система управления базами данных предоставляет вам возможность контролировать задание структуры и описание своих данных, работу с ними и организацию коллективного пользования этой информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение (задание структуры и описание) данных, обработка данных и управление данными. Все эти функциональные возможности в полной мере реализованы в Microsoft Access. В практике, как правило, необходимо решать и задачи с использованием электронных таблиц и текстовых процессоров. Например, после подсчета или анализа данных необходимо их представить в виде определенной формы или шаблоны. В итоге пользователю приходится комбинировать программные продукты для получения необходимого результата. В этом смысле все существенно упростят возможности, предоставляемые Microsoft Access.
СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.
Глава 1 Проектирование баз данных
1.1 Сбор информации о предметной области
С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.
В общем случае существуют два похода к выбору состава и структуры предметной области:
· Функциональный подход - он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае мы можем четко выделить необходимый минимальный набор объектов предметной области, которые должны быть описаны.
· Предметный подход - когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач.
Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.
Чаще всего на практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.
Данная база предназначена для ведения учета сборки оргтехники, в ней находятся 4 таблицы, в которые входят: «Служащие», «Товар», «Поставщик», «Движение товара». В таблицу «Служащие» входят такие атрибуты как: код служащего, ФИО, адрес, должность, заработная плата, образование, телефон. В таблицу «Товар» входят: код товара, вид, цена, количество. В таблицу «Поставщик» входят: код поставщика, ФИО, адрес, телефон, код товара. В таблицу «Движение товара» входят: код товара, код служащего, код движения товара, вид движения товара, оптовая цена закупки, розничная цена продажи, код поставщика.
1.2 Построение информационно-логической модели данных
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный, он требует обсуждений с заказчиком, со специалистами в предметной области. Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, как говорилось раньше, оно не должно быть привязано к конкретной СУБД.
Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить смысл предметной области.
Рассмотрим проектирование БД на примере предметной области «Оргтехника».
Пусть необходимо построить базу данных, содержащую информацию о системе учета сборки изделий [3]:
· перечень поставщиков;
· список служащих;
· сведения о движении товаров.
На основании анализа предметной области мы выделили следующие сущности модели «сущность-связь» («Entity Relationship» - ER-модели): «Поставщики», «Служащие», «Товар», «Движение товара».
На основании внимательного анализа предметной области можно выделить следующие сущности модели “сущность-связь”: «Движение товара», «Поставщик», «Служащие», «Товар», «Поставка фирме», «Поставщик», «Служба доставки», «Счет», «Товары» (рисунок 1).
Движение товараКод товараКод служащегоКод движения товараКод поставщикаВид движения товараОптовая цена закупкиРозничная цена продажи |
ПоставщикКод поставщикаКод товараФамилияИмяОтчествоТелефонАдрес |
ТоварКод товараВидЦенаКоличество |
СлужащиеКод служащегоФамилияИмяОтчествоАдресТелефонДолжностьЗарплатаОбразование |
Рисунок 1 - Сущности модели
Между выделенными сущностями можно выделить, например, следующие связи:
1. Поставщики поставляют товар.
2. Служащие принимают товар.
Если понимать язык условных обозначений, которые соответствуют категориям ER-модели, то ее можно легко «читать», следовательно, она доступна для анализа программистам-разработчикам, которые будут разрабатывать отдельные приложения. Она имеет однозначную интерпретацию, в отличие от некоторых предположений естественного языка, и поэтому здесь не может быть никакого недопонимания со стороны разработчиков [4]. Общий подход к построению базы данных с использованием ER-метода состоит, прежде всего, в построении инфологической модели, включающей в себя все важные сущности и связи. Следующим шагом в процессе проектирования базы данных является построение набора предварительных таблиц и указание предполагаемого первичного ключа для каждой таблицы.
Рисунок 2 - Приведение инфологической модели системы учета сборки изделий
1.3 Разработка логической структуры БД
В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализ корректности схемы являются так называемый функциональные зависимости между атрибутами БД. Некоторые зависимости между атрибутами отношений являются нежелательными из-за побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом под процессом модификации БД понимается внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов.
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, которая основана на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
Рисунок 3 - Приведение инфологической модели «Система учёта сборки изделий» к третьей нормальной форме
Таким образом, мы уже имеем схему базы данных «Система учёта сборки изделий», которую получили, воспользовавшись общими правилами перехода к реляционной модели данных. Она является корректной, поскольку в ней уже отсутствуют нежелательные отношения. Теперь необходимо решить вопрос о том, какую СУБД будем использовать и, затем, описать концептуальную схему в терминах выбранной СУБД. Необходимо также произвести описание внешних моделей в терминах выбранной СУБД. Воспользуемся для простоты СУБД MS Access. Для начала необходимо решить вопрос о назначении типа данных для каждого атрибута каждой сущности.
Глава 2. Создание и использование базы данных
2.1 Конструирования структур таблиц
Созданная база данных состоит из четырёх таблиц. В табл. 1 - 4 приведены параметры структуры таблицы базы данных «Оргтехника».
Таблица 1. Описание свойств полей таблицы Postavchik
Name Field |
Index |
Type |
Size |
AllowZero-Length |
|
Code Postavchik |
Primary Unique |
Text |
10 |
Нет |
|
Code Tovara |
Text |
15 |
Да |
||
Surname |
Text |
15 |
Да |
||
Name |
Text |
15 |
Да |
||
Patronymic |
Text |
15 |
Да |
||
Address |
Text |
15 |
Да |
||
Telephone |
Text |
15 |
Да |
Таблица 2 Описание свойств полей таблицы Tovar
Name Field |
Index |
Type |
Size |
Allow-Zero-Length |
Validation-Text |
|
Code Tovara |
Primary Unique |
Text |
10 |
Нет |
||
Vid |
Text |
15 |
- |
|||
Price |
Text |
15 |
||||
Quantity |
Text |
15 |
Таблица 3. Описание свойств полей таблицы Dvijenia Tovara
Name Field |
Index |
Type |
Size |
AllowZero-Length |
|
Code Dvijenia Tovara |
PrimaryUnique |
Text |
10 |
Нет |
|
Vid Dvijenia Tovara |
Text |
15 |
|||
Poznichnai Price Prodaji |
Text |
15 |
Нет |
||
Optovai Price Zacypki |
Text |
15 |
Да |
||
Code Tovara |
Index-Foreign |
Text |
10 |
Нет |
|
Code Slyjachego |
Index-Foreign |
Text |
10 |
||
Code Postavchik |
Index-Foreign |
Text |
10 |
Таблица 4. Описание свойств полей таблицы Slyjachego
Name Field |
Index |
Type |
Size |
AllowZero-Length |
|
Code Slyjachego |
PrimaryUnique |
Text |
10 |
Нет |
|
Name |
Text |
15 |
Да |
||
Surname |
Text |
15 |
Да |
||
Patronymic |
Text |
15 |
Да |
||
Adress |
Text |
15 |
Да |
||
Phone |
Text |
15 |
|||
Doljnost |
Text |
15 |
|||
Zarplata |
Text |
15 |
|||
Obrazovanie |
Text |
15 |
После того, как закончено проектирование и создание базы данных, следующий шаг - создание таблицы для хранения данных.
Таблицы - основа базы данных. Все другие объекты: запросы, формы и отчеты - зависят от таблиц.
При формировании новой таблицы базы данных работа с СУБД начинается с создания структуры таблиц.
2.2 Создание схемы данных
Логическая структура реляционной базы данных Access является адекватным отображением полученной модели базы данных магазина. Каждая сущность модели отображается соответствующей реляционной таблицей. Структура каждой реляционной таблицы определяется атрибутным составом соответствующей сущности, где каждый столбец, т.е. поле соответствует одному из атрибутов сущности. Ключевые атрибуты объекта образуют уникальный ключ реляционной таблицы. Для каждого столбца задается тип, размер данных и другие свойства. Строки, т.е. записи таблицы соответствуют экземплярам объекта и формируются при загрузке таблицы.
Связи между объектами модели реализуются одинаковыми атрибутами - ключами в соответствующих таблицах. При этом ключом всегда является уникальный ключ главной таблицы. Ключом связи в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа. Надо сказать, что ключ связи в подчиненной таблице называется внешним ключом.
В Access может быть создана схема данных, наглядно отображающая логическую структуру базы данных. Определение одно-многозначных связей в этой схеме должно осуществляться в соответствии с построенной моделью. Внешний вид схемы данных практически совпадает с графическим представлением теоретической модели (рисунок 4). На этом рисунке прямоугольники отображают таблицы базы данных с полным списком их полей, а связи показывают, по каким полям осуществляется взаимосвязь таблиц. Имена ключевых полей для наглядности выделяются и находятся в верхней части полного списка полей каждой таблицы.
Рисунок 4 - Схема данных базы данных системы учета оргтехники в реляционной СУБД MS Access
2.3 Создание запросов и форм
Запрос используется для изменения, просмотра и анализа данных. С помощью запросов можно просматривать, анализировать и изменять данные из нескольких таблиц. Они также используются в качестве источника данных для форм и отчётов.
SELECT
DvijeniaTovara.VidDvijeniaTovara, DvijeniaTovara.OptovaiPriceZacypki, DvijeniaTovara.PoznichhaiPriceProdaji, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM DvijeniaTovara, Tovar
WHERE (((DvijeniaTovara.CodeTovara)=[Tovar].[CodeTovara]));
SELECT
DvijeniaTovara.VidDvijeniaTovara, DvijeniaTovara.OptovaiPriceZacypki, DvijeniaTovara.PoznichhaiPriceProdaji, Postavchik.Surname, Postavchik.Name, Postavchik.Patronymic, Postavchik.Phone, Postavchik.Address, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM DvijeniaTovara, Postavchik, Tovar
WHERE (((DvijeniaTovara.CodeTovara)=[Tovar].[CodeTovara]) AND ((DvijeniaTovara.CodePostavchika)=[Postavchik].[CodePostavchika]))
ORDER BY Tovar.Vid;
SELECT
DvijeniaTovara.OptovaiPriceZacypki, DvijeniaTovara.PoznichhaiPriceProdaji, Slujachi.Surname, Slujachi.Name, Slujachi.Patronymic, Slujachi.Address, Slujachi.Phone, Slujachi.Doljnost, Slujachi.Zarplata, Slujachi.Obrazovanie, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM DvijeniaTovara, Slujachi, Tovar
WHERE (((DvijeniaTovara.CodeSlujachego)=[Slujachi].[CodeSlujachego])
AND ((DvijeniaTovara.CodeTovara)=[Tovar].[CodeTovara]));
SELECT
Postavchik.Surname, Postavchik.Name, Postavchik.Patronymic, Postavchik.Phone, Postavchik.Address, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM Postavchik, Tovar
WHERE (((Postavchik.CodeTovara)=[Tovar].[CodeTovara]));
SELECT
Slujachi.Surname, Slujachi.Name, Slujachi.Patronymic, Slujachi.Address, Slujachi.Phone, Slujachi.Doljnost, Slujachi.Zarplata, Slujachi.Obrazovanie, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM Slujachi, Tovar;
Наиболее часто используется запрос на выборку. При его выполнении данные, удовлетворяющие условиям отбора, выбираются из одной или нескольких таблиц и выводятся в определённом порядке.
Запрос можно создать с помощью мастера или самостоятельно.
Форма используется для различных целей, и не обязательно для представления данных из таблицы или запроса. Форму можно использовать для вывода данных как средство перемещения по элементам данных или как окно диалога для приема информации от пользователя.
2.4 Создание отчётов
Отчет - это способ представления данных в печатной форме и виде, определяемом пользователем. Отчеты полностью настраиваемы. Однако можно воспользоваться предопределенными отчетами, предоставляемыми Access.
В отличие от форм, которые тоже можно вывести на печать, отчет позволяет гибко расположить материал на странице (например, в колонках). В качестве источника данных для отчетов могут использоваться как таблицы, так и запросы.
Заключение
На основе БД сформировался новый пласт информационных технологий, которые эффективно используются во многих областях деятельности человека. Организации также нуждаются в специально разработанных БД. Они способствуют наиболее эффективной работе руководителя со всеми поставщиками, клиентами и многими другими подразделениями организации.
Microsoft Access создана на основе реляционной модели базы данных и предназначена для создания быстрых, эффективных баз данных, применяемых в быту и бизнесе. Кроме того, она способна подключаться к другим базам данных, создавая для вас широкий фронт работы с данными, независимо от того, где они находятся.
Оценивая преимущества и недостатки СУБД Microsoft Access и ее функциональные возможности, можно утверждать, что данная система обладает всеми необходимыми инструментами для создания, редактирования, хранения и ежедневного использования баз данных. Интерфейс программы прост и удобен, работа не требует получения большого количества дополнительных знаний.
В ходе выполнения курсовой работы была решена проблема создание базы данных для конкретной организации. Была также разработана программа, имитирующая часть работы БД данной организации. СУБД позволяет получать данные о клиентах, совершающих покупки, о проданных им товарах, о сделанных клиентами заказах, о работающих сотрудниках. В данном проекте была проанализирована предметная область и на этой основе были реализованы поставленные задачи.
Список литературы
1. Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 320 с.
2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1989. - 351 с.
3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.
4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. - 252 с.
5. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.
6. Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.
7. Корнеев И.К., Машурцов В.А. Информационные технологии в управлении. - М.: ИНФРА-М, 2001. - 158 с.
8. Мартин Дж. Планирование развития автоматизированных систем. - М.: Финансы и статистика, 1984. - 196 с.
9. Хаббард Дж. Автоматизированное проектирование баз данных. - М.: Мир, 1984. - 294 с.
Приложения
П 1. Схема данных базы
Схема данных базы данных системы учета оргтехники в реляционной СУБД MS Access
П 2 Листинг SQL-запросов
SELECT
DvijeniaTovara.VidDvijeniaTovara, DvijeniaTovara.OptovaiPriceZacypki, DvijeniaTovara.PoznichhaiPriceProdaji, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM DvijeniaTovara, Tovar
WHERE (((DvijeniaTovara.CodeTovara)=[Tovar].[CodeTovara]));
SELECT
DvijeniaTovara.VidDvijeniaTovara, DvijeniaTovara.OptovaiPriceZacypki, DvijeniaTovara.PoznichhaiPriceProdaji, Postavchik.Surname, Postavchik.Name, Postavchik.Patronymic, Postavchik.Phone, Postavchik.Address, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM DvijeniaTovara, Postavchik, Tovar
WHERE (((DvijeniaTovara.CodeTovara)=[Tovar].[CodeTovara]) AND ((DvijeniaTovara.CodePostavchika)=[Postavchik].[CodePostavchika]))
ORDER BY Tovar.Vid;
SELECT DvijeniaTovara.OptovaiPriceZacypki, DvijeniaTovara.PoznichhaiPriceProdaji, Slujachi.Surname, Slujachi.Name, Slujachi.Patronymic, Slujachi.Address, Slujachi.Phone, Slujachi.Doljnost, Slujachi.Zarplata, Slujachi.Obrazovanie, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM DvijeniaTovara, Slujachi, Tovar
WHERE (((DvijeniaTovara.CodeSlujachego)=[Slujachi].[CodeSlujachego]) AND ((DvijeniaTovara.CodeTovara)=[Tovar].[CodeTovara]));
SELECT Postavchik.Surname, Postavchik.Name, Postavchik.Patronymic, Postavchik.Phone, Postavchik.Address, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM Postavchik, Tovar
WHERE (((Postavchik.CodeTovara)=[Tovar].[CodeTovara]));
SELECT Slujachi.Surname, Slujachi.Name, Slujachi.Patronymic, Slujachi.Address, Slujachi.Phone, Slujachi.Doljnost, Slujachi.Zarplata, Slujachi.Obrazovanie, Tovar.Vid, Tovar.Price, Tovar.Quantity
FROM Slujachi, Tovar;
Подобные документы
Классификация архитектуры базы данных. Компьютерные сети и их виды. Обзор программных продуктов для учета компьютерной техники и оргтехники. Проектирование информационной структуры предметной области и программная реализация задачи учета оргтехники.
дипломная работа [1,9 M], добавлен 16.05.2017Особенности технологий создания и работы с базами данных. Реализация структуры базы данных в MS Visio и MS SQL Server. Виды манипуляций над данными, создание сложных запросов. Суть и характеристика прав пользователей, разработка клиентских приложений.
учебное пособие [2,2 M], добавлен 16.05.2013Алгоритмы обработки массивов данных. Система управления базами данных. Реляционная модель данных. Представление информации в виде таблицы. Система управления базами данных реляционного типа. Графический многооконный интерфейс.
контрольная работа [2,8 M], добавлен 07.01.2007Базы данных - важнейшая составная часть информационных систем. Проектирование базы данных на примере предметной области "Оргтехника". Сбор информации о предметной области. Построение информационно-логической модели данных. Разработка логической структуры.
курсовая работа [318,6 K], добавлен 24.12.2014Обоснование необходимости систем управления базами данных на предприятиях. Особенности разработки программного обеспечения по управлению базой данных, обеспечивающего просмотр, редактирование, вставку записей базы данных, формирование запросов и отчетов.
курсовая работа [1,5 M], добавлен 23.01.2010Основы безопасности персональных данных. Классификация угроз информационной безопасности персональных данных, характеристика их источников. Базы персональных данных. Контроль и управление доступом. Разработка мер защиты персональных данных в банке.
дипломная работа [3,2 M], добавлен 23.03.2018Процесс создания и определение задач полнофункциональной системы управления базами данных. Разработка структуры таблиц, хранящих данные и формирование запросов. Построение форм для ввода и просмотра информации в запросах и создание необходимых отчетов.
курсовая работа [1,1 M], добавлен 11.09.2010Исследование характеристик и функциональных возможностей системы управления базами данных Microsoft Office Access. Определение основных классов объектов. Разработка базы данных "Делопроизводство". Создание таблиц, форм, запросов, отчетов и схем данных.
реферат [1,3 M], добавлен 05.12.2014Описание структуры обучающего блока. Проектирование его алгоритма и лингвистического и информационного обеспечения. Организация его взаимодействия с базой данных. Разработка графического интерфейса. Программная реализация основных функций приложения.
дипломная работа [2,1 M], добавлен 20.12.2015Создание программ, позволяющих создавать базы данных. Создание таблицы базы данных. Создание схемы данных. Создание форм, отчетов, запросов. Увеличение объема и структурной сложности хранимых данных. Характеристика системы управления базой данных Access.
курсовая работа [2,1 M], добавлен 17.06.2013