Вы на НеОфициальном сайте факультета ЭиП

На нашем портале ежедневно выкладываются материалы способные помочь студентам. Курсовые, шпаргалки, ответы и еще куча всего что может понадобиться в учебе!
Главная Контакты Карта сайта
 
Где мы?
» » » ПРОЕКТИРОВАНИЕ ТАБЛИЦ В БАЗЕ ДАННЫХ

Реклама

Источник: База данных ГИБДД России

ПРОЕКТИРОВАНИЕ ТАБЛИЦ В БАЗЕ ДАННЫХ

Просмотров: 3656 Автор: admin
ТЕМА 1. ПРОЕКТИРОВАНИЕ ТАБЛИЦ В БАЗЕ ДАННЫХ
Урок 1.1. Проектирование базы данных
Краткая справка
База данных (БД) – структурированная совокупность взаимосвязанных  данных в рамках некоторой предметной области, предназначенная для длительного хранения во внешней памяти ЭВМ и постоянного применения. 
Реляционные БД – базы данных с табличной формой организации информации. Реляционная БД состоит из одной или нескольких взаимосвязанных таблиц (см. Приложение 2). 
Цели разработки БД:
• возможность хранения всех необходимых данных, касающихся предметной области; 
• возможность обработки данных, хранящихся в БД;
• исключение избыточности данных, хранящихся в БД.
Цели, которые нужно достичь при проектировании базы данных:
• сведение к минимуму числа хранимых в БД таблиц;
• нормализация таблиц для упрощения решения проблем, связанных с обновлением и удалением данных. 
Разработка базы данных заключается в тщательной проработке структуры БД и последующего непосредственного создания БД в среде выбранной СУБД (см. Приложение 1) и состоит из нескольких основных шагов: 
• проектирование базы данных;
• создание таблиц, составляющих БД;
• создание форм для ввода данных;
• создание запросов для статистической обработки данных;
• создание отчётов для формирования выходных документов;
• заполнение базы данных и её тестирование.
Проектирование базы данных включает три стадии:
• стадия формулировки требований, который заканчивается  составлением технического задания; 
• стадия проектирования, который заканчивается разработкой информационно-логической модели. 
• стадия реализации, на которой создаются таблицы, формы, запросы и  отчёты. 
На стадии формулировки требований выполняется анализ предметной  области на основе информационных потребностей будущих пользователей разрабатываемой базы данных. Эту стадию принято называть концептуальным проектированием базы данных, результатом которого является разработка концептуальной модели и выпуск технического задания. 8 
Концептуальная модель отображает основные (с точки зрения  моделирующего) понятия предметной области. Эта модель связана с исследованием предметной области и пространством задачи, но не с её решением. 
Построение концептуальной модели включает следующие шаги:
• идентификация понятий;
• определение ассоциаций, отражающие связи между понятиями;
• определение атрибутов, необходимых для выполнения информационных  требований. 
Список атрибутов можно разделить на следующие группы:
• список атрибутов (исходных данных), с которыми работает заказчик;
• список атрибутов (выходных данных), которые необходимы заказчику для управления структурой своего предприятия; 
• список атрибутов (выходных данных), которые не являются необходимыми для заказчика, но которые он должен предоставлять в другие организации (в вышестоящие структуры, в органы статистического учёта, прочие административные и контролирующие организации). 
Концептуальное проектирование подробно описано в Приложении 1.
Приведенные ниже пункты должны быть отражены в техническом задании.
Введение.
1. Основание для разработки.
2. Назначение и область применения программного изделия.
3. Требования к программному изделию:
3.1) функциональные требования с указанием исходных данных и результатов выполнения каждой из них; 
3.2) требования к надежности;
3.3) условия эксплуатации;
3.4) требования к составу и параметрам технических средств;
3.5) требования к информационной и программной совместимости.
4. Требование к программной документации.
5. Технико-экономические показатели.
6. Порядок контроля и приемки (не должны выходить за возможности  учебных аудиторий факультета "Экономика и право"). На стадии проектирования создается логическая модель данных, которая строится на основе концептуальной модели. Работа начинается с выделения информационных объектов, которые могут строиться на основе одного или нескольких понятий, выявляются связи между объектами. Затем составляется список свойств объектов. Для каждого свойства объекта подбирается наиболее подходящий тип данных. Определяются отношения между таблицами базы данных на основе связей между объектами данных, содержащимися в них. Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи «один ко многим» и «один к одному». 9 Далее полученные таблицы нормализуются. Первично нормализованная таблица содержит строки, в которых для каждого атрибута может быть только одно значение. Ненормализованной таблице обычно соответствует одна или несколько нормализованных таблиц-отношений. 
На стадии реализации выполняются:
• создание таблиц в рамках конкретной СУБД;
• проектирование формы для ввода данных в таблицы;
• определение операций, выполняемых при создании и изменении  информации в таблицах, включая обеспечение целостности данных; 
• выявление индексов, необходимых для ускорения выполнения запросов, для чего в каждой из таблиц намечают ключевое поле; 
• проектирование запросов для поиска и анализа информации в БД;
• разработка бланков отчётов, согласно принятым на предприятии  стандартам; 
• проработка вопросов безопасности путем распределения полномочий и прав доступа различных групп пользователей базы данных; 
• разработка процедуры создания резервных копий и восстановления исходных данных. 
Учебное задание 1.1
Выполнить этап проектирования БД для фирмы, занимающейся страхованием имущества от кражи, пожара и протечки (в произвольной комбинации). Желаемый вид страховки обозначается знаком "+". Клиент может застраховаться на любую «Страховую сумму», для чего делает «Страховой взнос» в размере: 
• 10% от страховой суммы, если имущество страхуется от пожара;
• 8% от страховой суммы, если имущество страхуется от протечки;
• 7% от страховой суммы, если имущество страхуется от кражи.
Страховка от кражи снижается на 1% при наличии стальной двери и еще на 2%, если в подъезде имеется вахтер. Взнос уменьшается на 1%, если страхование производится на все виды страховых случаев сразу. 
Тарифы страхования
Вид страховки Пожар Кража Протечка
Процент
страховки
10% 7% 8%

СТРАХОВАНИЕ ИМУЩЕСТВА 
Защита входа Вид страховки Страховой взнос
Клиент
стальная дверь вахтер пожар кража протечка
Страховая
сумма полный
со
скидкой
XXX Х Х Х Х Х ХХХ ??? ???
Х – обозначает, что информация вводится в БД, т.е. является независимыми (исходными)  данными; 
? – обозначает, что информация рассчитывается в БД, т.е. является зависимыми (выходными) данными. 10 
Технология выполнения учебного задания 1.1
Проектирование базы данных включает три стадии:
• стадия формулировки требований, которая заканчивается  составлением технического задания; 
• стадия проектирования, которая заканчивается разработкой логической модели; 
• стадия реализации, на которой создаются таблицы, формы, запросы и отчёты. 
1. Стадия формулировки требований
Основными понятиями области страхования имущества являются: 
• клиент – человек, который хочет застраховать свое имущество;
• агент – сотрудник фирмы, оказывающей страховые услуги;
• имущество – квартира;
• страховой полис – документ;
• страховые услуги;
• страховые льготы.
Ассоциации:
• клиент владеет имуществом;
• агент страхует имущество;
• страховой полис включает информацию о клиенте, имуществе, страховых  услугах и льготах. 
Агент
ФИО агента
Телефон
Место проживания
Страховые услуги
Страховая сумма
Страховой взнос
Вид услуги
1..n
1
Оказывает
Страховые
льготы
Процет скидки
Имущество
Адрес
1..n 1
Страхует
Клиент
ФИО клиента
Телефон
Место проживания 1..n 1
Владеет
Страховой
полис
1..n
1 Включает
0..n
1
Может включать
1
1
Описывается
0..n
1
1..n
1
1..n 1
1
1
1..n 1
1
1..n

Основные требования: 
• каждый клиент может заключить несколько договоров на страхование  различного имущества (не обязательно своего); 
• агент оказывает содействие клиенту при заключении договора, который завершается выдачей страхового полиса; 
• страховой полис включает как минимум одну страховую услугу;
• страховой полис может не включать страховых льгот.
Техническое задание
1.1. Введение
Необходимо спроектировать БД для фирмы, занимающейся страхованием  имущества. База данных должна разрабатываться в среде СУБД MS Access. В соответствии с практикой работы страховых фирм для каждого клиента составляется договор страхования, где указываются условия страхования и сумма страховки. На основании суммы страховки и видов страхования производится расчёт страховых взносов: полного и со скидкой. 
1.2. Основание для разработки БД
Основанием для разработки является учебное задание по курсу.
1.3. Назначение разработки БД
БД предназначена для хранения и обработки информации о договорах страхования имущества клиентов. 
1.4. Требование к БД
1.4.1. Требование к функциональным характеристикам В процессе работы фирмы в БД должна заноситься информация по каждому клиенту, который желает застраховать свое имущество, виды страхования, страховая сумма, страховой взнос с учётом скидок. Входными данными являются: номер договора, дата договора, информация об агенте, информация о клиенте, сумма страхования. Выходными данными являются: полный страховой взнос, страховой взнос со скидкой, квартальная премия агентов. 
Полный страховой взнос определяется в размере:
• 10% от страховой суммы, если имущество страхуется от пожара;
• 8% от страховой суммы, если имущество страхуется от протечки;
• 7% от страховой суммы, если имущество страхуется от кражи.
Размер страхового взноса снижается при страховании от кражи на 1% при  наличии стальной двери и еще на 2%, если в подъезде имеется вахтер. Размер страхового взноса уменьшается на 1%, если страхование проводится на все виды страховых случаев сразу. 
Размер квартальной премии агентов может назначаться по постоянной и прогрессивной шкале: 
В первом случае премия назначается в размере 10% от страховых взносов, полученных от страховых договоров за квартал. 12 
Во втором случае:
• если сумма страховых взносов меньше 10 000 руб., то премия назначается в  размере 10% от страховых взносов; 
• если сумма страховых взносов больше 10 000 руб., но меньше 20 000 руб.,
то премия назначается в размере 12% от страховых взносов;
• если сумма страховых взносов превышает 20 000 руб., то премия назначается в размере 15% от страховых взносов. 
Выходным документом является шаблон «Приказ о премировании сотрудников». В качестве отчётов будет предоставлена информация по деятельности страховых агентов за отчётный период. 
1.4.2. Требования к надежности БД
Специальных требований к обеспечению надежности функционирования БД не предъявляется. 
1.4.3. Условия эксплуатации БД
Все пользователи БД имеют равные полномочия для работы с БД. Обслуживающий персонал должен иметь базовую компьютерную подготовку (конечный пользователь). Для ведения БД достаточно одного сотрудника. 
1.4.4. Требования к составу и параметрам технических средств  База данных эксплуатируется под управлением СУБД MS Access-97 на ПК, не ниже Pentium 300, RAMM 32 Mb. 
1.4.5. Требования к информационной и программной совместимости Специальных требований к информационной и программной совместимости не предъявляется. 
1.5. Требования к документации БД 
Документацией к БД является полное описание технологии разработки БД.
1.6. Стадии и этапы разработки
Разработка БД включает следующие этапы:
• концептуальное проектирование БД, результатом которого должно быть
сформулированное техническое задание;
• построение информационно-логической модели;
• создание таблиц, форм, запросов и отчётов.
1.7. Порядок контроля и приемки БД
База данных должна быть заполнена с помощью составной формы. Каждая  таблица должна содержать не менее 20 записей. Все имеющиеся в БД запросы и отчёты должны быть протестированы. 13 
2. Стадия проектирования. Информационно-логическая модель На основе анализа концептуальной модели выделяем три информационных объекта (сущности): агенты, клиенты и договора (страховые полисы). Формируем список атрибутов, описывающих различные информационные объекты. 
Таблица 1.1
Имя элемента Использование Объект
Номер договора Ввод/вывод Договора
Дата договора Ввод/вывод Договора
ФИО агента Ввод/вывод Договора
Пол агента Ввод/вывод Договора
Дата рождения агента Ввод/вывод Договора
Город агента Ввод/вывод Договора
Телефон агента Ввод/вывод Договора
ФИО клиента Ввод/вывод Договора
Город клиента Ввод/вывод Договора
Телефон клиента Ввод/вывод Договора
Стальная дверь Ввод/вывод Договора
Вахтер Ввод/вывод Договора
Пожар Ввод/вывод Договора
Кража Ввод/вывод Договора
Протечка Ввод/вывод Договора
Страховая сумма Ввод/вывод Договора
Страховой взнос полный Вывод Рассчитывается
Страховой взнос со
скидкой
Вывод Рассчитывается
Каждый информационный объект будем описывать таблицей.  Проектируем таблицу Договора. Вышеперечисленных данных о клиентах и агентах оказывается недостаточно для организации БД, так как в них отсутствует идентифицирующее свойство. Может показаться, что в качестве такого идентифицирующего свойства можно использовать атрибут «Фамилия». Однако, в составе персонала фирмы могут работать однофамильцы, поэтому поле «Фамилия» не может использоваться в качестве ключевого. Лучше всего в качестве ключевого поля использовать дополнительный атрибут, например, номер агента, который будет индивидуальным для каждого агента. С другой стороны, однофамильцы могут встретиться и среди клиентов, кроме того, один и тот же клиент может оформить несколько договоров страхования. Поэтому для идентификации клиентов будем использовать атрибут номер клиента. Наличие полей «Номер Агента» и «Номер Клиента» в структуре таблиц Агенты и Клиенты позволит однозначно идентифицировать запись и, выделив эти поля в качестве ключевых, легко связать таблицы. 14 
Таблица 1.2
Имя элемента Тип данных Описание
Номер договора Числовой Номер договора
Дата договора Дата/время Дата договора
Номер агента Числовой
Идентификационный номер
агента
Дата рождения агента Дата/время Дата рождения агента
Пол агента Текстовый Пол агента
ФИО агента Текстовый ФИО агента
Город агента Текстовый Город агента
Телефон агента Текстовый Телефон агента
Номер клиента Числовой
Идентификационный номер
клиента
ФИО клиента Текстовый ФИО клиента
Город клиента Текстовый Город клиента
Телефон клиента Текстовый Телефон клиента
Стальная дверь Логический Стальная дверь
Вахтер Логический Вахтер
Пожар Логический Пожар
Кража Логический Кража
Протечка Логический Протечка
Страховая сумма Денежный Страховая сумма
Страховой взнос полный Денежный
Рассчитывается полный
страховой взнос
Страховой взнос со
скидкой
Денежный
Рассчитывается страховой
взнос со скидкой
Применяем к полученной таблице данных правила нормализации. Выделяем информацию об агентах и о клиентах соответственно в отдельные таблицы: Агенты и Клиенты. Между таблицами устанавливаем связи по ключевым полям «Номер Агента» и «Номер Клиента». Тип связей «один ко многим» устанавливается на стороне таблицы Договора. 15 Таблица Договора 
Связанные объекты: Агенты Тип связи: «один ко многим»
Клиенты Тип связи: «один ко многим»
Ключевое поле: «Номер Договора»
Таблица 1.3
Имя элемента Тип данных Описание
Номер Договора Числовой Номер договора
Дата Договора Дата/время Дата договора
Номер Агента Числовой Номер агента
Номер Клиента Числовой Номер клиента
Стальная Дверь Логический Стальная дверь
Вахтер Логический Вахтер
Пожар Логический Пожар
Кража Логический Кража
Протечка Логический Протечка
Страховая Сумма Денежный Страховая сумма

Таблица Агенты 
Связанные объекты: Договора Тип связи: «один ко многим»
Ключевое поле: «Номер Агента»
Таблица 1.4
Имя элемента Тип данных Размер Примечания
Номер агента Числовой Длинное целое
Номер личного дела
агента
Фамилия агента Текстовый 20 Фамилия агента
Имя агента Текстовый 15 Имя агента
Отчество агента Текстовый 15 Отчество агента
Пол Текстовый 1 Пол агента
Дата рождения Дата/время
Краткий
формат даты
Пол агента
Город Текстовый 15
Город проживания
агента
Телефон Текстовый 8 Телефон агента
16
Таблица Клиенты
Связанные объекты: Договора Тип связи: «один ко многим»
Ключевое поле: «Номер Клиента»
Таблица 1.5
Имя элемента
Тип
данных
Размер Примечания
Номер клиента Числовой Длинное целое Код клиента
Фамилия клиента Текстовый 20 Фамилия клиента
Имя клиента Текстовый 15 Имя клиента
Отчество клиента Текстовый 15 Отчество клиента
Город Текстовый 15 Город клиента
Улица Текстовый 20
Название улицы
клиента
Номер дома Текстовый 4 Номер дома клиента
Номер квартиры Числовой Длинное целое
Номер квартиры
клиента
Телефон Текстовый 8 Телефон клиента

Контрольные вопросы
1. Что такое база данных?
2. Что такое реляционная структура данных?
3. Что такое СУБД?
4. В чем заключается концептуальное проектирование базы данных?
5. В чем заключается разработка информационно-логической модели?
6. Что такое тип данных?
7. Каковы основные задачи нормализации?
8. Из каких соображений выбираются размеры текстового и числового полей? 

Информация

Комментировать статьи на нашем сайте возможно только в течении 60 дней со дня публикации.

Популярные новости

Статистика сайта



Rambler's Top100



 
Copyright © НеОфициальный сайт факультета ЭиП