Добавлен: 25.10.2018
Просмотров: 13551
Скачиваний: 370
СОДЕРЖАНИЕ
Глава 1. системный анализ предметной области
1.1 анализ объекта автоматизации
1.2 обзор информационных технологий
Глава 2. проектирование базы данных
2.1 Разработка инфологической модели
2.2 Обоснование выбора модели данных
2.3. Даталогическое проектирование
Глава 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
3.2. Физическое проектирование базы данных в СУБД
3.6. Реализация ограничений, автоматизация обработки данных в БД
Совершенно новый продукт Borland Delphi for Windows - система скоростной разработки приложений, основанная на объектно-ориентированном Паскале. Delphi объединяет визуальные средства быстрой разработки приложений, высокопроизводительный компилятор объектно-ориентированного языка, масштабируемый механизм доступа к данным и другие последние достижения в области компьютерных технологий.
Visual C++ – наиболее мощный объектно-ориентированный язык программирования, обладает неограниченной функциональностью. Предназначен для создания компонентов приложений для выполнения операций, критичных по скорости.
В качестве СУБД используется Microsoft Access 2013 т.к. в Access в полной мере реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи и обеспечивает целостность данных на уровне ядра (что предотвращает несовместимые операции обновления или удаления данных). Кроме того, таблицы в Access снабжены средствами проверки допустимости данных, предотвращающими некорректный ввод вне зависимости от того, как он осуществляется, а каждое поле таблицы имеет свой формат и стандартные описания, что существенно облегчает ввод данных. Access поддерживает все необходимые типы полей, в том числе текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка и поля объектов OLE. Если в процессе специальной обработки в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.
3.2. Физическое проектирование базы данных в СУБД
Цель физического проектирования – преобразование логической модели с учетом синтаксиса, семантики и возможностей выбранной целевой СУБД.
Физическая модель БД определяет способ размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Исторически первыми системами хранения и доступа были файловые структуры и системы управления файлами (СУФ), которые фактически являлись частью операционных систем. СУБД создавала над этими файловыми моделями свою надстройку, которая позволяла организовать всю совокупность файлов таким образом, чтобы она выглядела как единое целое и получала централизованное управление от СУБД. Однако непосредственный доступ осуществлялся на уровне файловых команд, которые СУБД использовала при манипуляции всеми файлами, составляющие хранимые данные одной или нескольких баз данных.
С учетом типов данных и ограничений, принятых в MS Access, опишем требования к таблицам.
Таблица 1
Таблица Сотрудники
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Табельный номер |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Фамилия |
Текстовый |
Размер поля |
25 |
|
Обязательное поле |
Нет |
||
|
Имя |
Текстовый |
Размер поля |
10 |
|
Обязательное поле |
Нет |
||
|
Отчество |
Текстовый |
Размер поля |
15 |
|
Обязательное поле |
Нет |
||
|
Дата рождения |
Дата и время |
Размер поля |
Краткий формат даты |
|
Индексированное поле |
Нет |
||
|
Должность |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
Таблица 2
Таблица Должность
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код должности |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Должность |
Текстовый |
Размер поля |
30 |
|
Обязательное поле |
Нет |
||
Таблица 3
Таблица Тип сделки
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код типа |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Тип сделки |
Текстовый |
Размер поля |
25 |
|
Обязательное поле |
Нет |
||
Таблица 4
Таблица Тип объекта
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код объекта |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Тип объекта |
Текстовый |
Размер поля |
55 |
|
Обязательное поле |
Нет |
||
Таблица 5
Таблица Улица
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код улицы |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Улица |
Текстовый |
Размер поля |
35 |
|
Обязательное поле |
Нет |
||
Таблица 6
Таблица Город
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код города |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Город |
Текстовый |
Размер поля |
35 |
|
Обязательное поле |
Нет |
||
Таблица 7
Таблица Клиенты
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код клиента |
Счётчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Фамилия |
Текстовый |
Размер поля |
35 |
|
Обязательное поле |
Нет |
||
|
Имя |
Текстовый |
Размер поля |
10 |
|
Обязательное поле |
Нет |
||
|
Отчество |
Текстовый |
Размер поля |
25 |
|
Обязательное поле |
Нет |
||
|
Дата рождения |
Дата и время |
Размер поля |
Краткий формат даты |
|
Индексированное поле |
Нет |
||
|
Город |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Улица |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
№ дома |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
№ квартиры |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Контактный телефон |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
Таблица 8
Таблица Недвижимость
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
Код_объекта |
Счетчик |
Размер поля |
Длинное целое |
|
Индексированное поле |
Да (совпадения не допускаются) |
||
|
Объект |
Текстовый |
Размер поля |
35 |
|
Обязательное поле |
Нет |
||
|
Город |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Улица |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
№_строения |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
№_квартиры |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Площадь |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Описание |
Текстовый |
Размер поля |
255 |
|
Обязательное поле |
Нет |
||
|
Сдача_в_аренду |
Логический |
Формат поля |
Да/Нет |
|
Индексированное поле |
Нет |
||
Таблица 9
Таблица Договор
|
Имя поля |
Тип данных |
Свойства полей |
|
|
Свойство |
Значение |
||
|
1 |
2 |
3 |
4 |
|
№_договора |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Код_объекта |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Код_клиента |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Тип_сделки |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Срок_аренды |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Стоимость_сделки |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Код_сотрудника |
Числовой |
Размер поля |
Длинное целое |
|
Индексированное поле |
Нет |
||
|
Дата_оформление договора |
Дата и время |
Размер поля |
Краткий формат даты |
|
Индексированное поле |
Нет |
||
3.3. Разработка представлений
Выбор структуры диалога — это первый из этапов, который должен быть выполнен при разработке интерфейса. Рассмотренные ниже четыре варианта структуры диалога являются разновидностями структуры типа «вопрос — ответ», тем не менее каждая из них имеет свои особенности и наиболее удобна для определенного класса задач.
Развитие диалога во времени можно рассматривать как последовательность переходов системы из одного состояния в другое. Очевидно, что ни одно из этих состояний не должно быть «тупиковым», т.е. пользователь должен иметь возможность перейти из любого текущего состояния диалога в требуемое (за один или несколько шагов). Для этого в ходе разработки интерфейса необходимо определить все возможные состояния диалога и пути перехода из одного состояния в другое. Другими словами, необходимо разработать сценарий диалога.
MS Ассеss позволяет организовывать удобный и интуитивно понятный интерфейс пользователя для работы с данными с помощью форм. Формами называются настаиваемые диалоговые окна, сохраняемые в базе данных в виде объектов специального типа. Формы содержат так называемые элементы управления, с помощью которых осуществляется доступ к данным в таблицах. Элементами управления являются текстовые поля для ввода и правки данных, кнопки, флажки, переключатели, списки, надписи, а также рамки объектов для отображения графики. Создание форм, содержащих необходимые элементы управления, существенно упрощает процесс ввода данных и позволяет предотвратить ошибки. Формы позволяют выполнять проверку корректности данных при вводе, проводить вычисления, и обеспечивают доступ к данным в связанных таблицах с помощью подчиненных форм.