Информационная система складского терминала

целесообразно будет разбить объектное отношение документов прихода на

несколько отдельных объектных отношений: документы прихода, карточка

товара, поставщики, операторы, расположение.

Определим атрибуты объектного отношения «Карточка товара»:

1. наименование товарной единицы;

2. производитель товарной единицы;

3. код продукта;

4. вес короба продукции;

5. высота короба продукции;

6. ширина короба продукции;

7. длина короба продукции;

8. цена короба продукции.

Определим атрибуты объектного отношения «Поставщики»:

1. код поставщика;

2. название поставщика;

3. адрес поставщика;

4. телефон поставщика;

5. расчетный счет поставщика;

6. № договора с поставщиком;

Определим атрибуты объектного отношения «операторы»:

1. фамилия оператора;

2. имя оператора;

3. отчество оператора;

4. адрес оператора;

5. телефон оператора;

Определим атрибуты объектного отношения «Документы прихода»:

1. № акта разгрузки;

2. оператор;

3. № товарно-транспортной накладной;

4. время создания акта разгрузки;

5. дата создания акта разгрузки;

6. № машины, с которой прибыла продукция;

7. поставщик;

8. водитель машины;

9. дата разгрузки;

10. время разгрузки;

Определим атрибуты объектного отношения «Расположение»:

1. № акта разгрузки;

2. код продукта;

3. количество коробов;

4. срок годности продукции;

5. адрес;

Информация о товарах будет располагаться в файле с именем «tovar.dbf» со

следующей структурой файла (Таблица 3.1.):

Таблица 3.1.

|Название |Имя поля |Тип поля |Длина |

|Название товара|Nаim_tov |текстовый |30 |

|Производитель |Naim_proizvod |текстовый |15 |

|товарной | | | |

|единицы | | | |

|Код продукта |Kod_prod |числовой |6 |

|Вес короба |Ves_prod |числовой |4 |

|продукции | | | |

|Ширина короба |Shir_prod |числовой |3 |

|продукции | | | |

|Высота короба |Visot_prod |числовой |3 |

|продукции | | | |

|Длина короба |Dlin_prod |числовой |3 |

|продукции | | | |

|Цена короба |Cena_prod |числовой |4 |

|продукции | | | |

Информация о поставщиках будет располагаться в файле с именем «postav.dbf»

со следующей структурой файла (Таблица 3.2):

Таблица 3.2.

|Название |Имя поля |Тип поля |Длина |

|код поставщика |Kod_post |числовой |5 |

|название |Naim_post |текстовый |15 |

|поставщика | | | |

|адрес |Adres_post |текстовый |30 |

|поставщика | | | |

|телефон |Telef_post |числовой |6 |

|поставщика | | | |

|расчетный счет |Ras_shet |числовой |30 |

|поставщика | | | |

|№ договора с |№_dogov |числовой |10 |

|поставщиком | | | |

Информация об операторах будет располагаться в файле с именем

«operators.dbf» со следующей структурой файла (Таблица 3.3.):

Таблица 3.3.

|Название |Имя поля |Тип поля |Длина |

|Фамилия |FIO1_oper |текстовый |10 |

|оператора | | | |

|Имя оператора |FIO2_oper |текстовый |8 |

|Отчество |FIO3_oper |текстовый |10 |

|оператора | | | |

|Адрес оператора|Adres_oper |текстовый |30 |

|Телефон |Telef_oper |числовой |6 |

|оператора | | | |

Информация о документах прихода будет располагаться в файле с именем

«prihod.dbf» со следующей структурой файла (Таблица 3.4.):

Таблица 3.4.

|Название |Имя поля |Тип поля |Длина |

|№ акта |№_akt |числовой |10 |

|разгрузки | | | |

|Оператор |operator |текстовый |10 |

|№ |№_TTN |числовой |5 |

|товарно-транспо| | | |

|ртной накладной| | | |

|Время создания |Time |time |8 |

|акта о | | | |

|разгрузке | | | |

|Дата создания |Data |data |10 |

|акта о | | | |

|разгрузке | | | |

|№ машины, с |№_cars |общий |10 |

|которой прибыла| | | |

|продукция | | | |

|Код поставщик |Kod_post |текстовый |15 |

|Водитель машины|Voditel |текстовый |10 |

|Дата разгрузки |Data1 |data |10 |

|Время разгрузки|Time1 |time |8 |

Информация о расположении будет располагаться в файле с именем «adress.dbf»

со следующей структурой файла (Таблица 3.5.):

Таблица 3.5.

|Название |Имя поля |Тип поля |Длина |

|№ акта |№_acts |числовой |10 |

|разгрузки | | | |

|Код продукта |Kod_prod |числовой |6 |

|Количество |Kol_case |числовой |3 |

|коробов | | | |

|Срок годности |BBD |общий |15 |

|продукции | | | |

|Адрес |Аdress |общий |15 |

Определим необходимые атрибуты объектного отношения документов отгрузки.

Анализ информации, которая должна содержатся в акте об отгрузки продукции

со склада, показывает, что следует выделить следующие атрибуты объектного

отношения документов отгрузки со склада:

1. № акта об отгрузки;

2. № заказа;

3. оператор;

4. время создания акта;

5. дата создания акта;

6. код клиента;

7. название клиента;

8. адрес клиента;

9. телефон клиента;

10. дата отгрузки

11. время отгрузки

12. код продукции

13. адрес продукции на складе

14. количество коробов

15. срок годности продукции

Используя данное объектное отношение, мы получим слишком громоздкую

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

иметь определенное количество разных адресов на складе для каждого кода

продукции в отдельности, то мы получим большое число строк, в которых будет

повторяться информация о клиентах, продукции, операторах. Исходя из данного

анализа целесообразно будет разбить объектное отношение документов отгрузки

на несколько отдельных объектных отношений: документы отгрузки, карточка

товара, клиенты, операторы, адрес отгрузки.

Объектные отношения карточка товара и операторы представлены выше.

Определим атрибуты объектного отношения «Клиенты»:

1. код клиента;

2. название клиента;

3. адрес клиента;

4. телефон клиента;

Определим атрибуты объектного отношения «Документы отгрузки»:

1. № акта отгрузки;

2. № заказа;

3. оператор;

4. время создания акта отгрузки;

5. дата создания акта отгрузки;

6. код клиента;

7. дата отгрузки;

8. время отгрузки;

Определим атрибуты объектного отношения «адрес отгрузки»:

1. код продукта;

2. количество коробов;

3. срок годности продукции;

4. адрес продукции

Информация о клиентах будет располагаться в файле с именем «klient.dbf» со

следующей структурой файла (Таблица 3.6.):

Таблица 3.6.

|Название |Имя поля |Тип поля |Длина |

|код клиента |Kod_klien |числовой |5 |

|название |Naim_klien |текстовый |15 |

|клиента | | | |

|адрес клиента |Adres_klien |текстовый |30 |

|телефон клиента|Telef_klien |числовой |6 |

Информация о документах отгрузки будет располагаться в файле с именем

«otgryska.dbf» со следующей структурой файла (Таблица 3.7.):

Таблица 3.7.

|Название |Имя поля |Тип поля |Длина |

|№ акта отгрузки|№_akt1 |числовой |10 |

|№ заказа |№_zakaz |числовой |10 |

|Оператор |operator |текстовый |10 |

|Время создания |Time2 |time |8 |

|акта oб | | | |

|отгрузки | | | |

|Дата создания |Data2 |data |10 |

|акта об | | | |

|отгрузки | | | |

|Код клиента |Kod_klien |общий |5 |

|Дата отгрузки |Data3 |data |10 |

|Время отгрузки |Time3 |time |8 |

Информация о расположении будет располагаться в файле с именем

«adress1.dbf» со следующей структурой файла (Таблица 3.8.):

Таблица 3.8.

|Название |Имя поля |Тип поля |Длина |

|№ акта oтгрузки|№_acts |числовой |10 |

|Код продукта |Kod_prod |числовой |6 |

|Количество |Kol_case |числовой |3 |

|коробов | | | |

|Срок годности |BBD |общий |15 |

|продукции | | | |

|Адрес |Аdress |общий |15 |

Инфологическая модель баз данных "Приход", "Уход" построенная с помощью

языка "таблицы-связи" представлена на рис. 3.9. /5/

3.4 Описание модулей программы

В виду громоздкости программного кода проекта в данном разделе приведем

описание одного модуля программы на примере модуля Unit1.pas. Этот модуль

описывает работу формы ввода пароля. Соответствующий листинг представлен в

приложении. Представленный исходный код модуля Delfi, написанный на

объектно-ориентированном языке Object Pascal реализует интерфейс

пользователя для ввода пароля. В списке Uses данного модуля присутствуют

ссылки на модули Unit2 и Unit 3. Благодаря этому данный

[pic]

модуль может вызывать во время выполнения программы вышеперечисленные

модули обращаться к их элементам. В разделе type перечислены визуальные

компоненты, принадлежащие форме Form1, а также приведены объявления

процедур, используемых в данном модуле. Процедура TForm1.Button1Click

выполняется при нажатии кнопки . Она нажимается тогда, когда пароль

введен в поле MaskEdit1. Процедура проверяет, есть ли в записях базы данных

«операторы» в поле «password» значение введенное в поле MaskEdit1. Если

найдена хотя бы одна запись, имеющая в поле «password» значение, введенное

в MaskEdit1, то программа продолжает работать. Если значение введенное в

MaskEdit1 не найдено приложение прекращает свою работу. После проверки

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

«операторы» в поле «status» стоит значение «оператор», то кнопки на главной

форме, доступные для администратора БД, делаются недоступными. Если поле

«status» содержит значение «администратор», то все кнопки на главной форме

становятся доступными. Значение полей «Fam» и «Status» присваивается меткам

на главной форме. В конце процедуры формы Form1 и Form2 делаются

невидимыми. Главная форма Form3 делается видимой. Процедура

TForm1.MaskEdit1KeyDown необходима для того, чтобы процедура

TForm1.Button1Click запускалась не только при нажатии кнопки , но и при

нажатии клавиши . Процедура TForm1.FormClose выполняется всегда, при

закрытии формы Form1. Форма Form1 делается невидимой, а главная форма Form3

наоборот отображается на экране как модальная.

4. Защита информации в ЛВС подразделения

4.1 Анализ возможностей системы разграничения доступа ОС Wndows NT.

Windows NT имеет средства обеспечения безопасности, встроенные в

операционную систему. Рассмотрим наиболее значимые из них:

Централизованное управление безопасностью

Для повышения удобства Windows NT имеет централизованные средства

управления безопасностью сети. Имеется возможность установки области и

связей доверия для централизации сетевого учета пользователей и другой

информации, относящийся к безопасности, в одном месте, облегчая управление

сетью и использование ее. При централизованном управлении безопасностью для

каждого пользователя имеется только одна учетная карточка и она дает

пользователю доступ ко всем разрешенным ему ресурсам сети. Можно

использовать только один сетевой компьютер, чтобы проследить за активностью

на любом сервере сети.

Управление рабочими станциями пользователей

Профили пользователя в Windows NT позволяют обеспечить большое удобство

пользователям и в то же самое время ограничить их возможности, если это

необходимо. Чтобы использовать профили пользователя для большей

продуктивности, имеется возможность сохранить на сервере профили,

содержащие все характеристики пользователя и установочные параметры, как

например, сетевые соединения, программные группы и даже цвета экрана. Этот

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

компьютере с Windows NT так, что предпочитаемая им среда следует за ним с

одной рабочей станции на другую. Для того, чтобы применять профили при

ограничении возможностей пользователя, необходимо добавить ограничения к

профилю, как например, предохранить пользователя от изменения программных

групп и их элементов, делая недоступными части интерфейса Windows NT, когда

пользователь будет регистрироваться в сети.

Слежение за деятельностью сети

Windows NT Server дает много инструментальных средств для слежения за

сетевой деятельностью и использованием сети. ОС позволяет просмотреть

серверы и увидеть, какие ресурсы они совместно используют; увидеть

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

и увидеть, какие файлы у них открыты; проверить данные в журнале

безопасности; записи в журнале событий; и указать, о каких ошибках

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

Начало сеанса на компьютере Windows NT

Всякий раз, когда пользователь начинает сеанс на рабочей станции Windows

NT, экран начала сеанса запрашивают имя пользователя, пароль и домен. Затем

рабочая станция посылает имя пользователя и пароль в определенный домен для

идентификации. Сервер в этом домене проверяет имя пользователя и пароль в

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

пароль идентичны данным в учетной карточке, сервер уведомляет рабочую

станцию о начале сеанса.

Сервер также загружает другую информацию при начале сеанса пользователя,

как например установки пользователя, свой каталог и переменные среды. По

умолчанию не все учетные карточки в домене позволяют входить в систему

серверов домена. Только карточкам групп администраторов, операторов

сервера, операторов управления печатью, операторов управления учетными

карточками и операторов управления резервным копированием разрешено это

делать.

Учетные карточки пользователей

Каждый человек, который использует сеть, должен иметь учетную карточку

пользователя в некотором домене сети. Учетная карточка пользователя

содержит информацию о пользователе, включающую имя, пароль и ограничения по

использованию сети, налагаемые на него. Имеется возможность также

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

в группы; группы облегчают предоставление прав и разрешений на ресурсы,

достаточно сделать только одно действие, дающее права или разрешения всей

группе.

Журнал событий безопасности

Windows NT позволяет определить, что войдет в ревизию и будет записано в

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

действия или осуществляется доступ к файлам. Элемент ревизии показывает

выполненное действие, пользователя, который выполнил его, а также дату и

время действия. Это позволяет контролировать как успешные, так и неудачные

попытки каких-либо действий.

Права пользователя

Права пользователя определяют разрешенные типы действий для этого

Страницы: 1, 2, 3, 4, 5, 6, 7, 8