На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. Предметная область играет большую роль в анализе, структурировании данных и позволяет классифицировать и формализовать информацию обо всех процессах данного исследования.
Предметная область — совокупность связанных между собой функций, задач управления, с помощью которых достигается выполнение поставленных целей, это часть реального мира, представляющая интерес для конкретного исследования.
В данном курсовом работе разработана база данных промышленного предприятия «Машзавод №1». Завод осуществляет деятельность по производству гидростоек, металлокрепь, узлы ГШО и ведет их ремонт. Гидростойки и гидропередвижки выпускаемые заводом аттестованы по высшей категории качества и получили Государственный знак качества. Завод экспортировал свою продукцию: Польшу, ГДР, Болгарию, Вьетнам, Румынию, Югославию, Индию, Мали и Мазамбик.
Машиностроение — отрасль народного хозяйства, определяющая уровень научно-технического прогресса, поскольку обеспечивает все отрасли машинами, оборудованием, приборами, а население — предметами потребления.
Для создания БД потребуются данные о выпускаемой данным предприятием изделия и ее типах, отделах и цехах, сотрудниках и занимаемых ими должностях, а также продажах и, соответственно, покупателях.
Схема работы очень проста. Клиент промышленного предприятия (все данные и контакты находятся в таблице Клиенты) делает заказ на определенное изделие (например, Гидроцилиндр ГЦ 2.00.000, по цене 5000 руб., 2 шт.).
Этот заказ заносится в таблицу Заказы. Предприятие начинает производить работу в цехах, где определенные сотрудники занимают свою должность и выпускают изделие определенного количества и далее осуществляется сама сделка: клиент получает товар, а мы получаем деньги за выполненный заказ. После этого проданный предприятием изделие вносится в таблицу Выполнение заказа. То есть фактически будут использоваться в основном 2 таблицы — на заказ товара и его выполнение. Остальные таблицы, формы, запросы базы будут нужны для информационной, правильной, четкой, работы. Чтобы можно было сразу узнать, кто заказал, кто произвел, описание изделия, посчитать суммы заказов, сделать отбор по определенным данным, обновить, удалить, добавить изделие, получить отчеты по изделиям и клиентам и выйти из базы.
Один из наиболее сложных этапов в процессе создания базы данных — разработка таблиц, так как результаты, которые должна выдавать база данных не всегда дают полное представление о структуре таблицы.
Создание таблицы базы данных в Microsoft Access
... в списке таблиц в окне базы данных появятся имя и значок новой таблицы. Ввести данные в созданную таблицу можно, открыв таблицу в режиме Таблицы. Существуют также и другие варианты, создания таблиц. Можно, например, создать таблицу с помощью запроса на создание таблицы. ... таблицами, в Microsoft Access используется схема данных (Relationships). Чтобы открыть схему данных, ... работы. Измеряется в ваттах ...
Таблицы должны содержать всю информацию разрабатываемой базы. В моем случае это Клиенты, Изделие, Цех, Работники, Выполнение заказа, Заказанные товары, Заказы. Все таблицы хранят максимально полную характеристику, информацию и описание для дальнейшей успешной работы с базой данных.
Для связи данных из разных таблиц, например, данные о заказчике и изделия, каждая таблица должна содержать набор полей или поле, где будет задаваться индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом. Именно благодаря ключам будет функционировать база данных, сопоставляя, связывая и формируя информацию из разных таблиц. Количество ключей варьируется от одного до нескольких. Вообще, ключ — это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.
Для проверки правильности работы базы необходимо создать несколько таблиц, определить связи между ними и ввести несколько записей в каждую таблицу, а затем посмотреть, отвечает ли база данных поставленным требованиям. Рекомендуется также создать черновые выходные отчеты и формы и проверить, выдают ли они требуемую информацию. Кроме того, необходимо исключить всевозможные повторения данных. Иначе база не будет работать и выдавать нужный запрос или информацию или будет работать с ошибками, что для серьезной организации неприемлемо.
Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные (в режиме конструктора таблиц).
После ввода создаются любые запросы, формы, отчеты, макросы и модули (удобнее, проще и правильнее создавать все с помощью мастеров).
2. Концептуальное проектирование
Прежде, чем начать проектирование БД, необходимо разобраться, как функционирует предметная область, для отображения БД. Для этих целей используются искусственные формализованные языковые средства.
В связи с этим, под инфологической моделью (ИЛМ) понимают описание предметной области, выполненное с использованием специальных языковых средств, независящих от программных средств.
ИЛМ должна строиться вне зависимости от того, будете ли Вы в дальнейшем использовать СУБД или пользоваться другими программными средствами для реализации своей ИС.
Требования, предъявляемые к ИЛМ:
— адекватность отображения предметной области;
— непротиворечивость;
— отражение взглядов и потребностей всех пользователей системы;
— недопущение неоднозначной трактовки модели;
— должна быть конечной, т.е. ограничение предметной области;
— легкость расширения;
— возможность композиции и декомпозиции модели;
— легко восприниматься разными категориями пользователей.
Центральной компонентой инфологической модели является описание объектов предметной области и связей между ними. ИЛМ является моделью данных, отображающей предметную область в виде совокупности информационных объектов и структурных связей между ними (ER — модель).
Базы данных, основные модели их организации
... однажды в единой базе данных. Различные приложения могут затем получать доступ к нужным им данным. Таким образом, избыточность информации устраняется, и приложения действительно начинают работать совместно. Не смотря на то ...
Графическое представление является более наглядным и простым для восприятия и анализа. Поэтому воспользуемся именно графическим способом отображения модели «Объект — Свойство — Отношение». Предметная область — Промышленное предприятие, объект отображает производство изделия для поставки клиентам. Каждое изделие не может иметь более чем одного владельца, ER-модель для БД промышленного предприятия представлена на рисунке1 и рисунок2
Рисунок1 — Диаграмма ER — типа
Рисунок 2 — Диаграмма ER-экземпляров
ER-модель удобна при проектировании информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей).
С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями. Важно отметить, что сами отношения также являются сущностями (выделяются в отдельные графические блоки), что позволяет устанавливать отношения на множестве самих отношений.
Связь (отношение) между объектом и его свойством может быть различной. Отношения могут быть типа:
— 1:1 (одно — однозначные);
— 1:М (одно — многозначные);
— М-М (много — многозначные);
— М:1 (многие к одному).
Модель на языке ЯИМ имеет следующий вид:
Цех (Код цеха, Код изделия, Код работника, Наименование, Дата ввода в строй, Дата последней реконструкций)
Выпуск (Код цеха, Код работника, Код изделия, Месяц, Количество изделий)
Клиенты (Код клиента, Код изделия, Ф.И.О., Адрес, Телефон клиента)
Работники (Код работника, Квалификация, Опыт работы, Заработная плата, Должность)
Изделие (Код изделия, Наименование, Диаметр штока, Рабочее давление, Размер поршня)
Заказы (Код заказа, Код клиента, Код изделия, Дата заказа, Количество заказа)
Выполнение заказа (Код выполнения заказа, Код изделия, Дата заказа, Дата выполнения, Количество изделия, Цена изделия)
Для наиболее распространенных реляционных БД можно предложить язык инфологического моделирования «Таблица — связь», который приведен на рисунке 3.
В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени и типа сущности. Строки таблицы — это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, располагаются рядом и обводятся рамкой.
Связи между сущностями указываются стрелками, направленных от первичных ключей или их составляющих.
Рисунок 3 — Инфологическая модель БД «Машзавод №1», построенная с помощью языка «Таблицы-связи»
3. Логическое проектирование
Логическое проектирование з
Цель логического проектирования базы данных состоит в создании логической модели данных для исследуемого предприятия.
Логическая модель, отражающая особенности представления о функционировании предприятия одновременно многих типов пользователей, называется глобальной логической моделью. Для создания глобальной логической модели данных предприятия можно выбрать один из двух основных подходов — централизованный подход или подход на основе интеграции представлений.
В процессе разработки логическая модель данных должна постоянно подвергаться проверке как на соответствие требованиям пользователей, так и на отсутствие избыточности данных, способной вызвать в будущем аномалии обновления.
Построенная логическая модель данных в дальнейшем будет востребована на этапе физического проектирования, а также на этапе эксплуатации и сопровождения уже готовой системы, позволяя наглядно представить любые вносимые в базу данных изменения.
На этом этапе желательно создание следующих документов:
- набора подсхем;
- спецификаций для физического проектирования приложений;
- руководства по разработке данных (интерфейсы пользователем и межпрограммные интерфейсы);
- руководства по сопровождению БД.
Определим функциональные зависимости реквизитов справочного документа «Машзавод №1» и выделим информационные объекты.
Функциональные зависимости документа «Клиенты» представлены в таблице 1.
Таблица 1 — Функциональные зависимости документа «Клиенты»
|
Документ |
Наименование реквизита |
Имя реквизит |
Функциональные зависимости |
|
|
Клиенты |
Код клиента |
КК |
||
|
Код изделия |
KI |
|||
|
Ф.И.О. |
KNM |
|||
|
Адрес |
KADR |
|||
|
Телефон клиента |
KTLPH |
|||
Функциональные зависимости документа «Заказы» представлены в таблице 2., Таблица 2 —
|
Документ |
Наименование реквизита |
Имя реквизита |
Функциональные зависимости |
|
|
Заказы |
Код заказа |
KZ |
||
|
Код клиента |
KK |
|||
|
Код изделия |
KI |
|||
|
Дата заказа |
ZDATE |
|||
|
Количество заказа |
ZKOL |
|||
Функциональные зависимости документа «Изделие» представлены в таблице 3., Таблица 3 —
|
Документ |
Наименование реквизита |
Имя реквизита |
Функциональные зависимости |
|
|
Изделие |
Код изделия |
KI |
||
|
Наименование |
INM |
|||
|
Диаметр штока |
IDS |
|||
|
Рабочее давление |
IRD |
|||
|
Размер поршня |
IRP |
|||
Функциональные зависимости документа «Цех» представлены в таблице 4.
Таблица 4 — Функциональные зависимости документа «Цех»
|
Документ |
Наименование реквизита |
Имя реквизита |
Функциональные зависимости |
|
|
Цех |
Код цеха |
KC |
||
|
Код работника |
KR |
|||
|
Код изделия |
KI |
|||
|
Наименование |
CNM |
|||
|
Дата ввода в строй |
CDS |
|||
|
Дата последней реконструкций |
CPR |
|||
|
Количество рабочих |
CKR |
|||
Функциональные зависимости документа «Работники» представлены в таблице 5.
Таблица 5 — Функциональные зависимости документа «Работники»
|
Документ |
Наименование реквизита |
Название станции |
Функциональные зависимости |
|
|
Работники |
Код работника |
KR |
||
|
Квалификация |
RKV |
|||
|
Опыт работы |
ROR |
|||
|
Заработная плата |
RZP |
|||
|
Должность |
RD |
|||
Функциональные зависимости документа «Расписание» представлены в таблице 6., Таблица 6 —
|
Документ |
Наименование реквизита |
Имя реквизит |
Функциональные зависимости |
|
|
Выпуск |
Код цеха |
ТRAIN |
||
|
Код изделия |
MK |
|||
|
Код работника |
ARRIVE |
|||
|
Месяц |
STAY |
|||
|
Количество изделий |
DEPARTURE |
|||
Функциональные зависимости документа «Выполнение заказа» представлены в таблице 7., Таблица 7 —
|
Документ |
Наименование реквизита |
Имя реквизита |
Функциональные зависимости |
|
|
Выполнение заказа |
Код выполнения заказ |
KVZ |
||
|
Код изделия |
KI |
|||
|
Дата заказа |
VZDZ |
|||
|
Дата прибытия |
VZDP |
|||
|
Количество изделий доставленной |
VZKID |
|||
|
Цена изделий |
VZCI |
|||
Для того, чтобы определить типы реального отношения объектов, установим связь между ними, которая указана в таблице 8.
Таблица 8
|
Номер связи отношения |
Объекты |
Тип реального отношения |
||
|
1. |
Изделие |
Цех |
1:? |
|
|
2. |
Изделие |
Выпуск |
1:? |
|
|
3. |
Изделие |
Выполнение заказа |
1:? |
|
|
4. |
Изделие |
Заказы |
1:? |
|
|
5. |
Изделие |
Клиенты |
1:? |
|
|
6. |
Клиенты |
Заказы |
1:? |
|
|
7. |
Работники |
Цех |
1:? |
|
Установление типов данных каждого атрибута указано в таблице 9, Таблица 9 — Таблицы БД «Машзавод №1»
|
Имя таблицы |
Имя поля |
Длина поля |
Тип данных |
Вид индекса |
|
|
Клиенты |
Код клиента |
4 |
Числовой |
ПУ |
|
|
Код изделия |
4 |
Числовой |
У |
||
|
Ф.И.О. |
50 |
Текстовый |
|||
|
Адрес |
— |
Текстовый |
|||
|
Телефон клиента |
9 |
Числовой |
|||
|
Заказы |
Код заказа |
4 |
Числовой |
ПУ |
|
|
Код клиента |
4 |
Числовой |
У |
||
|
Код изделия |
4 |
Числовой |
У |
||
|
Дата заказа |
— |
Дата / Время |
|||
|
Количество заказа |
Числовой |
||||
|
Изделие |
Код изделия |
4 |
Числовой |
ПУ |
|
|
Наименование |
50 |
Текстовый |
|||
|
Диаметр штока |
— |
Числовой |
|||
|
Рабочее давление |
— |
Числовой |
|||
|
Размер поршня |
— |
Числовой |
|||
|
Цех |
Код цеха |
4 |
Числовой |
ПУ |
|
|
Код изделия |
4 |
Числовой |
У |
||
|
Код работника |
4 |
Числовой |
У |
||
|
Наименование |
50 |
Текстовый |
|||
|
Дата ввода в строй |
— |
Дата / Время |
|||
|
Дата последней реконструкций |
— |
Дата / Время |
|||
|
Количество рабочих |
— |
Числовой |
|||
|
Работники |
Код работника |
4 |
Числовой |
ПУ |
|
|
Квалификация |
50 |
Текстовый |
|||
|
Опыт работы |
50 |
Текстовый |
|||
|
Заработная плата |
— |
Денежный |
|||
|
Должность |
50 |
Текстовый |
|||
|
Выпуск |
Код цеха |
4 |
Числовой |
ПУ |
|
|
Код изделия |
4 |
Числовой |
У |
||
|
Код работника |
4 |
Числовой |
У |
||
|
Месяц |
50 |
Текстовый |
|||
|
Количество изделий |
— |
Числовой |
|||
|
Выполнение заказа |
Код выполнения заказа |
4 |
Числовой |
ПУ |
|
|
Код изделия |
4 |
Числовой |
У |
||
|
Дата заказа |
50 |
Дата / Время |
|||
|
Дата выполнения |
50 |
Дата / Время |
|||
|
Количество изделий доставленной |
50 |
Числовой |
|||
|
Цена изделия |
— |
Денежный |
|||
Даталогическа модель БД «Темир — жолы» выглядит следующим образом (рисунок 4).
|
Клиенты |
Выполнение заказа |
Цех |
||||
|
Код клиента |
Код выполнения заказа |
Код цеха |
||||
|
Код изделия |
Код изделия |
Код изделия |
||||
|
Ф.И.О. |
Дата заказа |
Код работника |
||||
|
Адрес |
Дата выполнения |
Наименование |
||||
|
Телефон клиента |
Количество изделий доставленной |
Дата ввода в строй |
||||
|
Цена изделия |
Дата последней реконструкций |
|||||
|
Заказы |
Количество рабочих |
|||||
|
Код заказа |
Изделие |
|||||
|
Код изделия |
Код изделия |
Работники |
||||
|
Код клиента |
Наименование |
Код работника |
||||
|
Дата заказа |
Диаметр штока |
Квалификация |
||||
|
Количество заказа |
Рабочее давление |
Опыт работы |
||||
|
Размер поршня |
Заработная плата |
|||||
|
Выпуск |
Должность |
|||||
|
Код цеха |
||||||
|
Код изделия |
||||||
|
Код работника |
||||||
|
Месяц |
||||||
|
Количество изделий |
||||||
Рисунок 4. Даталогическая модель БД «Темир-жолы»
4. Физическое проектирование
база данные инфологический модель
4.1 Методы физической организации данных, Проектирование на физическом уровне реализуется средствами СУБД и зачастую автоматизировано.
Целью проектирования на данном этапе является создание описания СУБД — ориентированной модели БД. Следует учитывать, что на этой стадии разработки возможны возвраты не более ранние этапы ЖЦБД. Действия, выполняемые на этом этапе, слишком специфичны для различных моделей данных, поэтому их сложно обобщить. Остановимся на реляционной модели данных. В этом случае по физическим проектированием подразумевается:
- создание описания набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
- определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
- разработка средств защиты создаваемой системы.
Проектирование физической структуры заключается в определении места хранения БД (сервер, диск, папка), форматов хранимых данных на уровне отдельных полей таблиц БД. Цель физического проектирования БД — эффективное использование вычислительных ресурсов (дисковой памяти, времени центрального процессора и т.д.)
Физическая структура БД соответствует понятию внутренней модели.
Доступ к физическим записям во внешней памяти в большинстве СУБД осуществляется через считывание в оперативную память страниц файла данных, содержащих соответствующие записи. Непосредственная обработка записей производится в оперативной памяти, для чего СУБД образует и поддерживает специальные буферы, в которых временно размещаются страницы, содержащие обрабатываемые записи. После завершения обработки страницы с соответствующими записями «выталкивается «из буфера и фиксируется в дисковом файле.
Физические структуры организации файлов данных подразделяются на линейные и нелинейные.
В линейных структурах в одну страницу файла БД объединяются записи — кортежи одной таблицы (информационного объекта), которые располагаются в последовательном (линейном) порядке друг за другом. Каких-либо ссылок, указателей на связи между записями не предусматривается.
В нелинейных структурах
Преимущества линейных структур файлов БД — простота и эффективность доступа; недостаток — невысокая эффективность использования дискового пространства, так как в полях записей хранятся и пустые значения (т.е. физически занимают место).
В нелинейных структурах непосредственная адресация связанных записей обеспечивает более эффективный, чем в линейных структурах, доступ к данным. Недостаток нелинейных структур — значительные затраты и процедуры преобразования файла БД при любых операциях манипулирования записями (удаление, добавление и др.), т. к. помимо проблем определения мест размещения записей и появления пустых мест в файле добавляется проблема перенастройки указателей на связанные записи после изменения данных.
К компонентам (числу работ) этапа физического проектирования БД помимо способов организации данных и методов доступа относятся:
- управление свободной памятью,
- определение размеров физического блока,
- определение целесообразности сжатия данных и используемых методов сжатия.
Оперативная память — это запоминающее устройство, используемое для хранения данных, которыми пользователь может оперировать.
Для выполнения программы требуются данные. Они передаются от внешних запоминающих устройств в оперативную память. Оперативная память мала для хранения всей базы данных предприятия. Поэтому требуется внешнее запоминающее устройство (ВЗУ).
В соответствии с методами управления доступом различают устройства внешней памяти с произвольной адресацией и устройства с последовательной адресацией.
4.2 Разработка интерфейса для работы с БД
Для удобства ввода, изменения, удаления и модификации информации в базе данных системы, средствами MS Access, были спроектированы 7 форм.
Рисунок 5 — Вкладка «Формы»
В данной форме можно осуществить переход ко всем остальным формам, отчетам, а также произвести поиск. Главная кнопочная форма включает три вкладки:
- формы (рисунок 5);
- запросы (рисунок 6);
- формы и отчеты (рисунок 7).
Рисунок 6 — Вкладка «Запросы»
Рисунок 7 — Вкладка «Формы и отчеты»
Схема данных БД «Машзавод №1» представлена на рисунке 8.
Рисунок 8 — Схема данных БД «Машзавод №1»
Таблица «Клиенты» содержит информацию обо всех клиентах заказываемых изделия (рисунок 9).
Рисунок 9 — Таблица «Клиенты»
Таблица «Изделие» хранит сведения о изделиях, их характеристиках и размерах (рисунок 10).
Таблица «Цех» содержит информацию о цехах, которые расположены на территории промышленного предприятия «Машзавод №1» (рисунок 11).
Рисунок 10 — Таблица «Изделие»
Рисунок 11 — Таблица «Цех»
Таблица «Работники» хранит информацию о сотрудниках предприятия, занимаемыми ими должностями, заработная плата, изображена на рисунке 12.
Рисунок 12 — Таблица «Работники»
Таблица «Заказы» содержит информацию о заказах изделия и их количество (рисунок 13).
Рисунок 13 — Таблица «Заказы»
Таблица «Выпуск» хранит информацию о выпускаемых изделий (рисунок 14).
Рисунок 14 — Таблица «Выпуск»
Таблица «Выполнение заказа» содержит сведения о выполненных заказах, их количества и цена (рисунок 15).
Рисунок 15 — Таблица «Выполнение заказа»
Таким образом, в базе данных «Машзавод №1» имеются 7 взаимосвязанных таблиц, в которых отражается вся необходимая информация.
В форме «Выполнение заказа» представлена вся необходимая информация о выполненных заказах (рисунок 16).
В данной форме, нажав на кнопку «Изменить», также можно добавить либо удалить данные.
Рисунок 16 — Форма «Выполнение заказа»
Форма «Выпуск» представлена на рисунке 17.
Рисунок 17 — Форма «Выпуск»
Форма «Заказы» изображена на рисунке 18. Данная форма содержит данные о количестве заказа и дата осуществления заказа.
Рисунок 18 — Форма «Заказы»
Форма «Изделие» имеет следующий вид (рисунок 19).
Рисунок 19 — Форма «Изделие»
Форма «Клиенты» представлена на рисунке 20.
Рисунок 20 — Форма «Клиенты»
Форма «Работники» представлена на рисунке 21.
Рисунок 21 — Форма «Работники»
Форма «Цех» представлена на рисунке 22
Рисунок 22 — Форма «Цех»
Во вкладке «Формы и отчеты» главной кнопочной формы имеются отчеты, к которым можно осуществить переход и просмотреть.
В данной базе имеется отчет для предоставления информации по сумме выполненных заказов (рисунок 23).
Помимо этого, существует отчет по сумме заказа (рисунок 24).
На рисунке 25 изображен отчет о сумме количества выпуска изделия.
Кроме просмотра данных отчетов можно вывести на печать интересующий документ, щелкнув на кнопку «Печать», который находится в той же вкладке, что и отчеты.
Рисунок 23 — Отчет «Сумма выполненных заказов»
Рисунок 24 — Отчет «Сумма заказа»
Рисунок 25 — Отчет «Сумма количества выпуска»
Заключение
Результатом проведенной работы является база данных «Промышленного предприятия» в СУБД Microsoft Access, имеющая удобный пользовательский интерфейс, предназначенный для работы различных групп пользователей.
База данных может предоставить пользователю всю необходимую информацию о деятельности промышленных предприятий. Таким образом, первостепенная цель написания данного курсового проекта, а именно создание БД, позволяющей автоматизировать учет деятельности предприятий, выполнена.
В целом, БД отвечает следующим требованиям:
- содержит всю необходимую информацию о предприятиях, цехах, производственном процессе;
- имеет удобный пользовательский интерфейс;
- обеспечивает выполнение операций хранения и модификации, соблюдает правила обновления данных;
- соблюдает сроки хранения данных, несет ответственность за их сохранность и достоверность, обеспечивает санкционированный доступ;
- обеспечивает архивирование и восстановление данных.
Разработанная база данных может иметь широкое применение. Ее могут использовать прикладные программисты, учебные заведения, студенты, проходящие курс по сходной тематике. Особенно рекомендуется использовать БД статистическим организациям: исчезнет необходимость в многотомных бумажных картотеках, в утомительной ручной работе над разработкой статистических данных. Также, данную базу можно использовать в бухгалтериях каждого отдельного использованного в базе предприятия. Кроме того, компьютер может вести поиск и изменять данные гораздо быстрее человека и лучше выполнять механическую работу.
База данных проста в использовании, что даже неопытный пользователь сможет легко разобраться, как с ней работать. Для понимания ее функционирования не требуется знаний особых разделов проектирования баз данных, специальных навыков программирования и знаний экономических дисциплин. Не возникнет проблем с использованием этой БД и при наличии компьютера, обладающего минимальной вычислительной мощностью.
Недостатками в этой БД является недостаточная информация о предприятиях: нет информации о директоре, об окладах рабочим, о специализации цехов, о продажах изделий и об их остатках. Возможно, не везде предусмотрены условия на вводимые данные, не до конца продумана идея доступа к базе данных: уровни и группы пользователей.
Список использованной литературы
[Электронный ресурс]//URL: https://inzhpro.ru/kursovaya/razrabotka-bazyi-dannyih-predpriyatiya/
1. Омарова Ш.Е. Проектирование баз данных. КЭУК. Караганда, 2004
2. Диго С.М. Базы данных: проектирование и управление: Учебник. — М.: Финансы и статистика, 2005. — 592 с.
3. Диго С.М. Учебное пособие по курсу «Базы данных» / Московский международный институт эконометрики, информатики, финансов и права. — М., 2004. — 177 с.
4. Андерсен В. Базы данных Microsoft Access. Проблемы и решения. — М.: Изд. центр «Академия», 2001
5. Баркер, Ф. Скотт. Использование Microsoft Access 97.: Пер. с англ. — К.: Диалектика, 1997.
6. Борис Карпов. Microsoft Office. Справочник. Санкт — Петербург, 2000.
7. Боуман Дж.С., Эмерсон С.Л., Дарновски М. Практическое руководство по SQL. Издательство: Вильямс, 2002.
8. Брызгалов Е.В., Шестаков А.П. и др., журнал «Информатика и образование», статья «Уроки по Access», 2000 г.
9. Виллариал Б. Программирование Access 2002 в примерах. Издательство: КУДИЦ-Образ, 2003.
10. Морозова Н.С., Морозов М.А. Информационные технологии в социально-культурном сервисе и туризме. 4-е издание. — М.: Изд. центр «Академия», 2006.
11. Омельченко Л.Н. Самоучитель СУБД. — СПб.: БХВ-Петербург, 2003.
12. Стивенс Р. Программирование баз данных, 2-е издание. Издательство: Бином-Пресс, 2007.
13. Фиайли К. SQL. Руководство по изучению языка. Издательство: ДМК Пресс, Питер, 2004.
