База данных "Кредитная история"

Размещено на http://www.allbest.ru/

Департамент образования города Москвы

Государственное бюджетное образовательное учреждение среднего профессионального образования

Колледж предпринимательства №15 города Москвы

ПЦК "Информационные технологиям"

Курсовая работа

по дисциплине "Основы проектирования баз данных"

Тема

База данных "Кредитная история"

Выполнил: студент группы ИС0111

Смирнов А.А.

Руководитель: преподаватель ПЦК

"Информационные технологии"

Перлова О.Н.

Москва

2013



Оглавление

Введение

1. Реляционная модель данных

1.1 Нормализация

1.2 Избыточность данных

1.2.1 Декомпозиция

1.2.2 Функциональная зависимость

1.3 Дефекты проектирования БД

1.4 Построение запросов

2. Исследование предметной области

2.1 Проектирование БД

2.2 Таблицы предметной области

2.3 Практическое создание БД

2.4 Практическое построение запросов

Заключение

Список литературы



Введение

база нормализация таблица реляционный

В процессе работы над курсовой мы должны осуществить постановку задачи, описать исследуемую предметную область, выполнить проектирование структуры базы данных (БД) и разработку полной программы, взаимодействующей с БД, для автоматизации функций пользователей. При выполнении работы необходимо научится работать со специальной технической и справочной литературой. Прежде всего, стоит разобраться, в том, что такое база данных. База данных -- представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины. Проектирование базы данных будет по теме: «Кредитная история»В базе данной кредитной истории хранятся все сведения о заемщике и о кредиторе. Если быть очень организованным человеком, то, используя специальную структуру каталогов и подкаталогов, можно легко справиться с несколькими сотнями таблиц. Но как собрать информацию обо всех клиентах и их заказах, если эти данные разбросаны по отдельным текстовым файлам и электронным таблицам? Как сохранить связи между файлами при вводе новой информации? Как убедиться, что данные вводятся правильно? Что делать, если одна и та же информация может потребоваться нескольким пользователям, но при этом нельзя допустить, чтобы два человека в одно и то же время корректировали одни и те же данные? Ответы на эти вопросы и на многие другие будут предоставлены в ходе выполнения данной курсовой работы.



1. Реляционная модель данных

Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими». Основа любой реляционной модели -- таблица, организованная как структура типа столбец-строка (по ходу статьи, я могу использовать слово «поле», вместо слова «столбец»). Таблица (не считая связывающих) является представлением какого-то объекта, который вы хотите хранить в БД.

Основа любой реляционной модели -- таблица, организованная как структура типа столбец-строка (по ходу статьи, я могу использовать слово «поле», вместо слова «столбец»). Таблица (не считая связывающих) является представлением какого-то объекта, который вы хотите хранить в БД.

Почти все современные системы основаны на реляционной (relational) модели управления базами данных. Название "реляционная" связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся (related) только к одному конкретному объекту. Кроме того, с данными двух типов (например, о клиентах и заказах) можно работать как с единым целым, основанным на значениях связанных между собой (related) данных. Например, если включать фамилию и адрес клиента в каждый его заказ, то это привело бы к хранению повторяющейся информации. Поэтому в реляционной системе информация о заказах содержит поле данных, куда вводится код клиента, по которому информация о каждом заказе объединяется с данными о соответствующем клиенте.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

Структурный аспект (составляющая) -- данные в базе данных представляют собой набор отношений.

Аспект (составляющая) целостности -- отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект (составляющая) обработки (манипулирования) -- РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

Для лучшего понимания РМД следует отметить три важных обстоятельства:

модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;

для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно -- явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;

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

Принципы реляционной модели были сформулированы в 1969--1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks», ставшей классической.

Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).

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

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

Кроме того, в состав реляционной модели данных включают теорию нормализации:

Нормализацией схемы базы данных называется процедура, производимая над базой данных с целью удаления в ней избыточности. Целью нормализации реляционной базы данных является устранение недостатков структуры базы данных, приводящих к избыточности, которая, в свою очередь, потенциально приводит к различным аномалиям и нарушениям целостности данных. Нормализация несет с собой немало преимуществ. Очевидно, что в нормализованной базе данных уменьшается вероятность возникновения ошибок, она занимает меньше места на жестком диске и т.д.

1.1 Нормализация

Первая нормальная форма (1НФ)

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

1.Кортежи не упорядочены

2.Атрибуты не упорядочены и различаются по наименованию

3.Все значения атрибутов аномарны (неделимы)

Рассмотрим аномалии (недостатки) первой нормальной формы.

Избыточное дублирование данных. Все наименования будут дублироваться в каждой строке нашей таблицы.

Аномалия включения. Пока изделие не будет выпущено, информация о нем (проектируемом или ранее снятом с производства) будет отсутствовать в базе. Аномалия удаления. Если изделие не выпускается в отчетный период, то информация об изделии исчезнет из базы. Аномалия корректировки. Если меняется, например, название изделия, то нужно откорректировать наименование не в одной строке, а во всех строках таблицы, где оно встречается.

Для устранения этих недостатков продолжим процесс нормализации.

Вторая нормальная форма (2НФ)

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

Третья нормальная форма (3НФ)

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

1.2 Избыточность данных

1.2.1 Декомпозиция

Декомпозиция отношений проводится, чтобы исключить избыточное дублирование в отношениях. Выделяют два типа декомпозиций отношений: без потерь и с потерями. Декомпозиция без потерь происходит тогда, когда после соединения вновь полученных отношений получается исходное отношение. Смысл декомпозиции заключается в том, что исходное отношение разбивается на несколько отношений таким образом, чтобы впоследствии соединение вновь образованных отношений позволило получить исходное отношение. Такая декомпозиция получила название декомпозиции без потерь.

Процесс декомпозиции следует всегда начинать со следующих операций:

с определения (идентификации) всех атрибутов, подлежащих хранению в БД.

установления между ними функциональных зависимостей.

1.2.2 Функциональная зависимость

Если значения кортежа на некотором множестве атрибутов единственным образом определяют значения на другом множестве атрибутов, говорят, что имеет место функциональная зависимость. Функциональная зависимость обозначается X >Y

Избыточная функциональная зависимость - зависимость, заключающая в себе такую информацию, которая может быть получена на основе других зависимостей, имеющихся в базе данных. Все не ключевые атрибуты отношения функционально зависят от ключа с разной степенью зависимости. Таким образом, первичным ключом является атрибут или группа атрибутов, которые являются детерминантами всех функциональных зависимостей отношения. Более точно - один из минимальных наборов атрибутов, от которых функционально зависят все остальные атрибуты отношения.

1.3 Дефекты проектирования БД

Аномалии - это проблемы, возникающие в данных из-за дефектов проектирования БД. Существуют три вида аномалий: вставки, удаления и модификации.

Аномалии вставки: нельзя вставить данные о клиенте, который пока не участвует не в одном проекте. Причина: Хранение в одном отношении данных о разных сущностях.

Аномалия обновления: одни и те же сведения повторяются во многих кортежах отношения. Причина: избыточность данных.

Аномалия удаления: при удалении кредитной истории удаляется информация о том, какая кредитная история была у клиента.

1.4 Построение запросов

Запрос позволяет выбрать необходимые данные из одной или нескольких взаимосвязанных таблиц, произвести вычисления и получить результат в виде виртуальной таблицы. Полученная таблица может использоваться в качестве источника данных в следующих запросах, формах, отчетах, страницах доступа к данным. Через запрос можно производить обновление данных в таблицах, добавление и удаление записей.

С помощью запроса можно выполнить следующие виды обработки данных:

выбрать записи, удовлетворяющие условиям отбора;

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

произвести вычисления в каждой из полученных записей;

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

произвести обновление полей в выбранном подмножестве записей;

создать новую таблицу базы данных, используя данные из существующих таблиц;

удалить выбранное подмножество записей из таблицы базы данных; добавить выбранное подмножество записей в другую таблицу.



2. Исследование предметной области

Что такое кредитная история

Прежде всего, кредитная история - это своего рода информация о заемщике, о его действиях на рынке кредитования. Кредитная история содержит данные о том, брал ли когда-либо человек кредиты, вовремя ли погашал их, и есть ли на сегодняшний день какая либо задолженность по кредитам.

Заёмщик -- сторона по кредитным отношениям, получающая кредит и принимающая на себя обязательство возвратить в установленный срок ссуженную стоимость и уплатить процент за время пользования ссудой.

Кредитная история физического лица состоит из трех частей: титульной, основной и дополнительной (закрытой) части.

* Титульная

* Основная

* Дополнительная

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

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

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

2.1 Проектирование БД

Базы данных (БД) составляют в настоящее время основу компьютерного обеспечения информационных процессов, входящих практически во все сферы человеческой деятельности. Тематика СУБД поистине безгранична и многогранна.

Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом этапе проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает лучшими свойствами, чем предыдущая.

Нормализация отношений - это формальный аппарат ограничений на формирование отношений, который позволяет устранить дублирование и потенциальную противоречивость хранимых данных, уменьшает трудозатраты на ведение БД.

Каждой нормальной форме соответствует некоторый набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером набора ограничений является ограничение первой нормальной формы -- значения всех атрибутов отношения атомарные. Поскольку требование первой нормальной формы является базовым требованием классической реляционной модели базы данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию.

В основе процесса нормализации лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два, или более отношения, удовлетворяющей требованиям следующей нормальной формы.

Теория нормализации основана на наличии зависимостей между атрибутами отношения. Основными видами зависимостей являются:

функциональные;

многозначные;

транзитивные.

Базовым является понятие функциональной зависимости, поскольку на его основе формируются определения всех остальных видов зависимостей. Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональную зависимость В от А обозначают А В. Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. При этом А и В могут быть составными, то есть состоять из двух и более атрибутов.

Зависимость, при которой каждый не ключевой атрибут зависит от всего составного ключа и не зависит от его частей, называется полной функциональной зависимостью. Если атрибут А зависит от атрибута В, а атрибут В зависит от атрибута С (С В А), но обратная зависимость отсутствует, то зависимость А от С называется транзитивной.

Многозначная зависимость. Говорят, что один атрибут отношения многозначно определяет другой атрибут того же отношения, если для каждого значения первого атрибута существует множество соответствующих значений второго атрибута. Многозначные зависимости могут быть:

один-ко-многим (1:М);

многие-к-одному (М:1);

многие-ко-многим (М:М).

Каждая ступень процесса нормализации приводит схему отношений в последовательные нормальные формы. Для каждой ступени имеются наборы ограничений. Выделяют следующую последовательность нормальных форм:

первая нормальная форма (1НФ);

вторая нормальная форма (2НФ);

третья нормальная форма (3НФ);

усиленная 3НФ или нормальная форма Бойса-Кодда (БКНФ);

четвертая нормальная форма (4НФ);

пятая нормальная форма (5НФ).

Отношение находится в первой нормальной форме (1НФ), когда каждая строка содержит только одно значение для каждого атрибута (столбца), то есть все атрибуты отношения имеют единственное значение (являются атомарными).

Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и каждый не ключевой атрибут полностью функционально зависит от всех составляющих первичного ключа. Если атрибут не зависит полностью от первичного ключа, то он внесен ошибочно и должен быть удален. Нормализация производится путем нахождения существующего отношения, к которому относится данный атрибут, или созданием нового отношения, в который атрибут должен быть помещен.

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится во 2НФ и ни один из его не ключевых атрибутов не связан функциональной зависимостью с любым другим не ключевым атрибутом. Атрибуты, зависящие от других не ключевых атрибутов, нормализуются путем перемещения зависимого атрибута и атрибута, от которого он зависит, в новое отношение.

Формально, для приведения схемы в 3НФ необходимо исключить все транзитивные зависимости.

Нормальная форма Бойса-Кодда (БКНФ) является развитием ЗНФ и требует, чтобы в отношении были только такие функциональные зависимости, левая часть которых является потенциальным ключом отношения. Потенциальный ключ представляет собой атрибут (или множество атрибутов), который может быть использован для данного отношения в качестве первичного ключа. Фактически первичный ключ - это один из потенциальных ключей, назначенный в качестве первичного. Детерминантом называется левая часть функциональной зависимости. Отношение находится в БКНФ тогда и только тогда, когда каждый детерминант отношения является потенциальным ключом.

Алгоритм приведения ненормализованных схем в 3НФ показан на рис.1. На практике построение 3НФ в большинстве случаев является достаточным и приведением к ней процесс построения реляционной БД заканчивается.



Рис.1

Нормальные формы высших порядков (4НФ и 5НФ) представляют больший интерес для теоретических исследований, чем для практики проектирования БД. В них учитываются многозначные зависимости между атрибутами. Полной декомпозицией отношения называют такую совокупность произвольного числа его проекций, соединение которых позволяет получить исходное отношение.



2.2 Таблицы предметной области

Сделаны следующие виды таблиц: Клиенты, Договора, Сведения.

Титульной части кредитной истории соответствует таблица Клиенты

Клиент	Дата рождения	Паспортные данные	Адрес регистрации	Место работы

Основной части кредитной истории соответствует таблица Договор

Договор	Клиент	Тип кредита	Сумма	Срок займа	Первоначальный взнос	Годовые %

Дополнительной (закрытой) части кредитной истории соответствует таблица Сведения

Место работы	Зарплата	Семейное положение	Информация о кредитах, взятых ранее	Запросы об истории

Мы можем получить из БД все сведения о клиенте; дате рождения клиента; его паспортные данные; адрес регистрации; место работы; тип кредита, который он взял; о сумме кредита; о сроках займа; о первоначальном взносе и годовых процентах; а так же о заработной плате клиента, его семейном положении; о кредитах, которые он брал ранее (если таковы имеются); так же узнать о том, кто и когда запрашивал кредитную историю данного клиента.

2.3 Практическое создание БД

Для создания базы данных используется среда Microsoft SQL Management Studio. Сначала необходимо создать саму базу данных. Для этого используется оператор CREATE DATABASE

Создание БД

Создание таблиц

Сведения:

Клиенты:



Договор:

2.4 Практическое построение запросов

1. По номеру договору найти клиента:



2. По типу кредита найти клиента:

3. Узнать, кто брал кредит на 5 и более лет:



4.Узнать сведение о клиенте:

5. Найти клиентов у которых годовой процент равен 11:



6. По месту работы узнать запросы о кредитах



Заключение

В курсовой работе показан метод проектирования и создания базы данных. В основе этого метода лежит нормализация. Были показаны структура таблиц, связи между ними и их содержание. Полученные теоретические и практические навыки в проектировании баз данных при изучении этой темы однозначно являются очень ценными.



Список литературы

Карпова Т.С. Базы данных: модели, разработка. - СПб.: Питер, 2001, 304 с.

SQL запросы для простых смертных / Хернандес Дж.М. Вьескас Дж.Л, 2003.

Кренке Д. Теория и практика построения баз данных: [пер.с англ] / Д. Кренке. - 9 - изд. - СПб.: Питер, 2005. -858 с.

Ульман Дж., Введение в системы баз данных. - М.: Лори, 2010. -374 с.

http://www.sql-tutorial.ru/

Размещено на Allbest.ru

...