Бизнес – правила:

• 
  Сведенья о клиентах хранятся 5 лет с момента последнего заказа;
  
• 
  При отказе от поставленного автомобиля с клиента удерживается 9% суммы оплаты по счёту, данная величина должна регулироваться;
  
• 
  просрочка предоставления автомобиля клиенту оплачивается фирмой «ЮГ-АВТО» из расчёта 0,2% в день от стоимости проката, данная величина может регулироваться;
  
• 
  При сдаче автомобиля клиентом после указанных сроков с клиента удерживается штраф: 110% от суммы за прокат за день в день.
  
• 
  При пропаже автомобиля и неявки клиента на клиента возбуждается уголовное дело по факту угона.
  
• 
  вся ответственность за автомобиль во время его использования возлагается нВ клиента. И в случае аварии по вине клиента ремонт делается за счёт клиента.
  

Требования к программе:

Программа должна работать под управлением операционных систем MS Windows 95, MS Windows 98, MS Windows NT, MS Windows 2000, MS Windows XP.

Перечень вводимой информации:

адрес

дата

водительские права

запрос

количество

имя

марка машины

номер

номер и серия паспорта

номер кредитки

отчество

состояние

цвет

цена

фамилия

Перечень печатных отчётов:

• 
  номенклатура предлагаемых к прокату автомобилей;
  
• 
  список клиентов;
  
• 
  анализ прокатов;
  
• 
  список заказов;
  
• 
  счёт на прокат.
  

Требования к оснащению офиса фирмы компьютерной теникой:

ПЭВМ со следующими характеристиками:

- процессор не ниже Pentium II 500МГц;

- объем ОЗУ не менее 128 Мб;

- НГМД 3,5 (1,44 Мб);

- НЖМД не менее 8 Гб;

- графический адаптер не хуже SVGA 8 Мб;

- монитор не хуже SVGA 0.26, 15 дюймов;

- сетевая плата, совместимая с Ethernet;

- манипулятор типа “мышь”;

- струйный или лазерный принтер формата А4.
Пользователи банков данных.
Как любой программно-организационно-технический комплекс, Банк Данных существует во времени и в пространстве. Он имеет определённые стадии своего развития:

1. 
   Проектирование
   
2. 
   Реализация
   
3. 
   Эксплуатация
   
4. 
   Модернизация и развитие
   
5. 
   Полная реорганизация
   

---

На каждом этапе своего существования с банком данных связаны разные категории пользователей.

Основные категории пользователей и их роль в функционировании банка данных:

• 
  Конечные пользователи. Это основная категория пользователей, в интересах которых и создаётся банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты фирмы, рассматривающие каталог автомобилей, которые доступны для проката, с обобщённым или подробным описанием того или иного автомобиля. Регулярными пользователями могут быть сотрудники фирмы, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении их должностных обязанностей. Например, менеджер имеет в своём распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать поступление новых автомобилей для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.
  
• 
  Администраторы банка данных. Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации.
  
• 
  Разработчики и администраторы приложений. Это группа пользователей, которая функционирует во время проектирования, создания и реорганизации банка данных. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединённых в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из базы данных, которая требуется для конкретного приложения.
  

---

Наиболее сложные обязанности возложены на группу администратора БД. В составе группы администратора БД должны быть:

• 
  системные аналитики;
  
• 
  проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;
  
• 
  проектировщики технологических процессов обработки данных;
  
• 
  системные и прикладные программисты;
  
• 
  операторы и специалисты по техническому обслуживании..
  

Модель данных.
Общие положения

Ядром любой базы данных является модель данных. Модель данных представляет

собой множество структур данных, ограничений целостности и операций

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

объекты предметной области и взаимосвязи между ними.

Модель данных — совокупность структур данных и операций их обработки.

СУБД основывается на использовании иерархической, сетевой или реляционной

модели, на комбинации этих моделей или на некотором их подмножестве [I].

Рассмотрим три основных типа моделей данных: иерархическую, сетевую и

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

между собой по определенным правилам. Объекты, связанные иерархическими

отношениями, образуют ориентированный граф (перевернутое дерево).

К основным понятиям иерархической структуры относятся: уровень, элемент

(узел), связь. Узел — это совокупность атрибутов данных, описывающих

некоторый объект. На схеме иерархического дерева узлы представляются

вершинами графа. Каждый узел на более низком уровне связан только с одним

узлом, находящимся на более высоком уровне. Иерархическое дерево имеет

только одну вершину (корень дерева), не подчиненную никакой другой вершине

и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные)

узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в

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

К каждой записи базы данных существует только один (иерархический) путь

от корневой записи.

---

Сетевая модель данных

В сетевой структуре при тех же основных понятиях (уровень, узел, связь)

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

Реляционная модель данных
Понятие реляционный (англ. relation — отношение) связано с разработками

известного американского специалиста в области систем баз данных Е. Кодда.

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

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

формального аппарата алгебры отношений и реляционного исчисления для

обработки данных.

Реляционная модель ориентирована на организацию данных в виде двумерных

таблиц. Каждая реляционная таблица представляет собой двумерный массив и

обладает следующими свойствами:

. каждый элемент таблицы — один элемент данных;

. все столбцы в таблице однородные, т.е. все элементы в столбце имеют

одинаковый тип (числовой, символьный и т.д.) и длину;

. каждый столбец имеет уникальное имя;

. одинаковые строки в таблице отсутствуют;

. порядок следования строк и столбцов может быть произвольным.

Отношения представлены в виде таблиц, строки которых соответствуют кортежам

или записям, а столбцы — атрибутам отношений, доменам, полям.

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

запись, называется простым ключом (ключевым полем). Если записи однозначно

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

имеет составной ключ.

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

ввести в состав ключа второй таблицы (возможно совпадение ключей); в

противном случае нужно ввести в структуру первой таблицы внешний ключ —

ключ второй таблицы.




Процесс проектирования.

Построение ДПД:

В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается,

---

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

Прокат автомобилей [1]
Сбор заявок [1.1]
Прием заявок [1.1.1]
Анализ заявок [1.1.2]
Сохранение заявок [1.1.3]
Сбор сведений о клиенте [1.2]
Прием информации о клиенте [1.2.1]
Анализ информации о клиенте [1.2.2]
Сохранение информации о клиенте [1.2.3]
Сбор сведений о наличии авто [1.3]
Запись сведений о наличии ВС [1.3.3]

---

Смотрите также файлы

• Разработка концепции проекта для сервиса обслуживания электровелосипедов "Электровел".docx

• Рубежный контроль к разделу 1 Дидактические основы дистанционного, электронного обучения и обучения с применением дистанционных образовательных технологий .doc

• Настоящая Карелия.docx

• Кру диктанты т, А, Т, а, п. Дыбысты диктант. , н, л, р. Буынды диктант.docx

• Торжественная линейка (трек 1) фанфары (трек 2) фон ведущих.doc