Понятие баз данных

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

Введение

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

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

В данном курсовом проекте необходимо создать базу данных «Банк», которую будем разрабатывать в среде MS Access, в ней есть поддержка работы со всеми стандартными видами данных, а так же MS Access входит в состaв программ MS Office, поэтому является доступной для пользователя.



1. Понятие баз данных

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

достаточно большие объемы информации;

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

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

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

высокая скорость доступа к данным;

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

удобство и простота конструирования пользователем запросов, форм и отчетов для выборки данных. Создание базы данных, ее поддержка и обеспечение доступа пользователей к ней осуществляется с помощью специального программного инструмента - системы управления базами данных [1].

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

Различают 2 класса СУБД:

1) системы общего назначения;

2) специализированные системы [4].

Системы СУБД общего назначения не ориентированы на какую-либо конкретную предметную область или на информационные потребности конкретной группы пользователей. Реализуются как программный продукт, способный функционировать на некоторой модели ЭВМ в определенной операционной системе. Использование СУБД общего назначения в качестве инструментального средства для создания информационных систем, основанных на технологии баз данных, позволяет существенно сокращать сроки разработки и экономить трудовые ресурсы.

В процессе реализации своих функций СУБД постоянно взаимодействует с базой данных и с другими прикладными программными продуктами пользователя.

Современные СУБД имеют следующие возможности:

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

позволяют вставлять, удалять, обновлять и извлекать информацию из базы данных посредством языка запросов (SQL);

большинство СУБД могут работать на компьютерах с разной архитектурой и под разными операционными системами;

многопользовательские СУБД имеют развитые средства администрирования баз данных.

В работе с СУБД возможны следующие режимы: создание, редактирование, поиск, манипулирование. Под манипулированием понимаются такие действия с БД, как с целым: просмотр; копирование файлов, например на бумажный носитель; сортировка данных по заданному признаку и т. д.

Для работы с базой данных СУБД должна обеспечивать:

возможность внесения и чтения информации;

работу с большим объемом данных;

быстроту поиска данных;

целостность данных (их непротиворечивость);

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

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

СУБД могут использоваться как в однопользовательском, так и в многопользовательском режиме.

Данную работу мы будем выполнять в MicrosoftAccess, которая обладает всеми чертами классической системы управления базами данных. Access - это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки приложений баз данных. 

MicrosoftAccess называет объектами все, что может иметь имя. В базе данных Access основными объектами являются таблицы, запросы, формы, отчеты, макросы и модули. В других СУБД, как правило, термин база данных обычно относится только к файлам, в которых хранятся данные. В MicrosoftAccess база данных включает в себя все объекты, связанные с хранимыми данными. Ниже приведен список основных объектов базы данных Access.

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

Запрос. Объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц. Для создания запроса можно использовать бланк QBE (запрос по образцу) или инструкции SQL (структурированный язык запросов). Можно создать запросы на выборку, обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц.

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

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

Макрос. Объект, представляющий собой структурированное описание одного или нескольких действий, которые должен выполнить Access в ответ на определенное событие.

Модуль. Объект, содержащий программы, написанные на языке VisualBasic для приложений [1].



2. Этапы проектирования базы данных

Процесс проектирования включает в себя следующие шаги:

Определение задач, стоящих перед базой данных.

Сбор и анализ документов, относящихся к исследуемой предметной области.

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

Создание модели предметной области.

Определение групп пользователей и перечня задач, стоящих перед каждой группой.

Выбор аппаратной и программной платформы для реализации БД.

Выбор СУБД.

Создание логической схемы БД.

Создание схем отношений, определение типов данных атрибутов и ограничений целостности.

Нормализация отношений.

Определение прав доступа пользователей к объектам БД.

Написание текста создания основных объектов базы данных на языке SQL в синтаксисе выбранной СУБД.

Написание текста создания вспомогательных объектов базы данных [1].

Все эти шаги выполняются в 5 этапов:

Инфологическое проектирование.

Определение требований к операционной обстановке, в которой будет функционировать информационная система.

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

Логическое проектирование БД.

Физическое проектирование БД.[5]

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

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

Этап инфологического проектирования. На этапе инфологического проектирования строится инфологическая модель предметной области. Инфологической моделью предметной области называется описание предметной области, выполненное с использованием специальных языковых средств, без ориентации на используемые в дальнейшем программные и технические средства. Данная модель содержит исходную информацию о предметной области, необходимую для проектирования структуры базы данных. Эта информация мало зависит от особенностей СУБД. Более того, ИЛМ может успешно применяться для проектирования информационных систем, имеющих "небанковскую" организацию. Описание этой модели в терминах соответствующих языковых средств называется концептуальной схемой данных.

На этапе даталогического проектирования строится даталогичекая модель. Даталогическая модель (ДЛМ) представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в СУБД, в среде которой проектируется база данных. Описание логической структуры данных на языке СУБД называется внутренней схемой данных.

На этапе физического проектирования строится физическая модель. Физическая модель определяет используемые запоминающие устройства и способы физической организации данных на них. Эта модель служит для привязки даталогической модели к среде хранения и обычно строится с учетом возможностей, предоставляемых СУБД. Описание структуры организации данных на физических носителях информации называется схемой хранения данных.

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

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

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



2.1 Инфологическое проектирование базы данных

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

Что лежит в основе процессов, характеризующих исследуемую предметную область?

Как эта область функционирует?

Где формируются данные, отражающие процессы, присущие предметной области?

Кто выполняет эти процессы?

Когда выполняются те или иные действия, свойственные этим процессам?

Почему эти действия выполняются?

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

Инфологическая модель включает в себя следующие основные компоненты:

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

описание информационных потребностей пользователей;

ограничения целостности;

лингвистические отношения;

алгоритмические связи показателей [4].

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

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

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

Пример ER-диаграммы для банка (рис.1):



Рисунок 1 - ER-диаграмма

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

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

Атрибут - это некоторое свойство объекта реального мира. Каждая сущность (как отражение некоторого объекта предметной области) должна обладать определенным набором атрибутов. Для всех экземпляров одной сущности набор атрибутов одинаков, но их значения для каждого конкретного экземпляра сущности могут различаться.

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

Существует два основных типа доменов: базовый домен и типизированный домен.

К базовым доменам обычно относятся следующие:

множество символьных строк любой длины и структуры, в состав которых входят символы любого;

множество числовых значений;

множество булевских данных [6].

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

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

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

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

предпочтение отдается тем возможным ключам, семантика которых устойчива и не допускает неоднозначного толкования [6].

Возможные ключи, не ставшие первичным ключом, объявляются как альтернативные ключи. Каждому альтернативному ключу присваивается порядковый номер. В документации к проекту каждый альтернативный ключ дополнительно помечается заключенными в круглые скобки буквами AK (AlternativeKey), за которыми следует порядковый номер ключа. Такая пометка располагается справа от имени каждого атрибута, входящего в альтернативный ключ. Один атрибут может быть отмечен как часть более чем одного альтернативного ключа. Атрибуты первичного ключа также могут быть частью альтернативного ключа.

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

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

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

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

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

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

Основные типы связей:

определенная связь (отражает отношение между сущностями типа «один ко многим»);

неопределенная связь (отражает отношение между сущностями типа «многие ко многим»);

связь типа категория (отражает отношение между сущностями типа «род-вид», связь типа «один к одному») [1].

При организации определенной связи между двумя сущностями устанавливается связь типа «один ко многим»: мощность одного конца связи соответствует значению «много», другого - значению «один». Сущность, находящаяся в этой связи со стороны "один", называется родительской, а со стороны «много» - дочерней.

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

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

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

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

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

Ограничения могут быть внутренними (неявными) и явными.

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

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

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

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

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

модель уровня сущностей;

модель уровня ключей;

полно-атрибутная модель [3].

Модель уровня сущностей является моделью нижнего уровня и применяется для работы проектировщика информационной системы с экспертами моделируемой системы. Модель включает сущности и связи между ними, которые отражают основные бизнес правила предметной области, и допускает присутствие всех типов связей. Графическое представление этой модели называется ER-диаграммой (EntityRelationshipDiagram).

Модель уровня ключей является дальнейшим развитием ER-модели и содержит более подробное представление данных. Она содержит описание всех сущностей, связей между ними, первичных и внешних ключей. Эта модель не допускает наличия неопределенных связей и требует их предварительного преобразования в определенные связи. Модель является переходным звеном от модели уровня сущностей к полному логическому описанию предметной области. Графическое представление этой модели называется KB-диаграммой (KeyBasedDiagram).

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

Каждая из этих моделей строится на определенном этапе инфологического проектирования. Этапы инфологического проектирования:

Инициирование проекта.

Определение сущностей.

Построение модели уровня сущностей.

Построение модели уровня ключей.

Построение полно-атрибутной модели [3].

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

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

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

Следующим шагом проектирования является составление предварительного списка сущностей. Сначала на основе анализа предметной области определяются кандидаты в сущности. Для этого выявляют экземпляры объектов предметной области с одинаковыми характеристиками и объединяют их в одну сущность-кандидат.

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

можно ли описать этот объект, т.е. можно ли получить о нем информацию?

имеет ли этот объект характеризующие его свойства?

можно ли получить информацию об этих свойствах?

можно ли выделить несколько образцов этого объекта, т.е. набор экземпляров этого объекта с одинаковыми свойствами?

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

является ли этот объект характеристикой чего-либо, т.е. описывает ли этот объект некоторый другой объект?

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

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

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

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

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

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

2.2 Определение требований к операционной обстановке

На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, определение типа и конфигурации конкретной ЭВМ, выбор типа и версии операционной системы. Объём вычислительных ресурсов зависит от предполагаемого объёма проектируемой базы данных и от интенсивности их использования. Если БД будет работать в многопользовательском режиме, то требуется подключение её к сети и наличие соответствующей многозадачной операционной системы [1].

2.3 Выбор СУБД и других программных средств

Выбор СУБД осуществляется на основании таких критериев, как тип модели данных и её адекватность потребностям рассматриваемой ПрО; характеристики производительности; набор функциональных возможностей; удобство и надежность СУБД в эксплуатации; стоимость СУБД и дополнительного программного обеспечения.



2.4 Логическое проектирование реляционной БД

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

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

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

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

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

разбить составные атрибуты на атомарные;

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

установить идентифицирующую определенную связь от старой сущности к каждой новой сущности.

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

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

установить идентифицирующую определенную связь от старой сущности к новой.

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

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

установить необязательную не идентифицирующую определенную связь от новой сущности к старой.

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

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

связь между новыми сущностями не устанавливается.

2.5 Физическое проектирование БД

Этап физического проектирования заключается в определении схемы хранения, т.е. физической структуры БД. Схема хранения зависит от той физической структуры, которую поддерживает выбранная СУБД. Физическая структура БД, с одной стороны, должна адекватно отражать логическую структуру БД, а с другой стороны, должна обеспечивать эффективное размещение данных и быстрый доступ к ним. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL, DataDefinitionLanguage) выбранной СУБД. Принятые на этом этапе решения оказывают огромное влияние на производительность системы [5].



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

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

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

В базе данных регистрируется следующая информация:

1. Информация об организации:

ИНН организации

Название

Телефон

Адрес

ФИО директора

Годовой доход

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

Номер платежного поручения

ИНН организации

Название организации

ИНН сотрудника

ФИО сотрудника

Дата поступления

Отметка о выполнении

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

Данные о сотрудниках, включая ИНН, ФИО, стаж работы, дату рождения и номер отдела, к которому они прикреплены, содержатся в документах следующей формы:

ИНН сотрудника

ФИО сотрудника

Номер отдела

Стаж работы (полных лет)

Дата рождения

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

Номер отдела

ИНН сотрудника

ФИО главного

Телефон отдела

ФИО главного заполняется из базы данных по соответствующему ИНН. Данные о менеджерах, включая ИНН, ФИО, стаж работы и дату рождения хранятся в документах следующей формы:

ИНН главного

ФИО главного

Стаж работы (полных лет)

Дата рождения



3.1 Схема данных

Общая схема данных представлена на рис. 2.

Рисунок 2 - Общая схема данных

Типы полей (рис. 3-9):

Рисунок 3 - Определение типа полей таблицы «Банк»



Рисунок 4 - Определение типа полей таблицы «Компании»

Рисунок 5 - Определение типа полей таблицы «Организации»

Рисунок 6 - Определение типа полей таблицы «Отдел»



Рисунок 7 - Определение типа полей таблицы «Платежное поручение»

Рисунок 8 - Определение типа полей таблицы «Сотрудник»

Рисунок 9 - Определение типа полей таблицы «Шеф»

3.2 Технология доступа к данным

Доступ ко всем формам, запросу и отчету осуществляется через главную кнопочную форму (рис. 10):

Рисунок 10 - Вид кнопочной формы

Доступ к данным непосредственно через таблицы невозможен. Для обеспечения удобства и корректности добавления и редактирования информации в БД доступ к данным, содержащимся в таблицах, осуществляется через формы.

Для просмотра и редактирования данных об организации, а также просмотра и редактирования дополнительной информации об организации созданы формы (рис. 10-11):

Рисунок 11 - Создание формы для кнопки «Организации»



Рисунок 12 - Создание формы для кнопки «Компании»

Информация о платежном поручении представлена в форме (рис. 13):

Рисунок 13 - Создание формы для кнопки «Банк»

Для просмотра, ввода и редактирования данных о сотрудниках, отделах и менеджерах созданы формы (рис. 14-16):

база данные проектирование средство

Рисунок 14 - Создание формы для кнопки «Сотрудник»



Рисунок 15 - Создание формы «Шеф»

Рисунок 16 - Создание формы «Отдел»

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

Запрос на выборку «Сотрудники, проработавшие более 5ти лет» - организуется доступ к таблице Сотрудники. Данный запрос содержит информацию о сотрудниках, которые работают в банке более 5-ти лет (рис. 17):

Рисунок 17 - Пример создания запроса

Отчет (рис. 18):

Рисунок 18 - Отчет проделанного запроса

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



Заключение

В начале выполнения курсового проекта были изложены теоретические основы построения баз данных.

В проектной части работы была выполнена постановка задачи построения базы данных для банка. В ходе проектирования базы данных были пройдены все этапы проектирования: описание информационных объектов предметной области, проектирование инфологической модели предметной области, логическое и физическое проектирование БД. В качестве СУБД была выбранаMicrosoftAccess.

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

Средствами СУБД MicrosoftAccess создан удобный пользовательский интерфейс. Приложение позволяет решать все задачи, сформулированные в задании на курсовую работу. Это позволяет сделать вывод, что задание выполнено полностью.

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



Список использованной литературы

1. Карпова И.П. Базы данных: Учебное пособие по курсу «Базы данных» - М., РИО МГИЭМ, 2009. - 118 с.

2. Агальцов В.П.. Базы данных. В 2-х кн. Книга 2. Распределенные и удаленные базы данных. Учебник. - М.: ИД «ФОРУМ»: ИНФРА-М, 2011.- 360 с.

3. Советов Б.Я., Цехановский В.В., Чертовской В. Д. Базы данных: теория и практика. Учебник для бакалавров.- М.: Юрайт-Издат, 2012. - 463 с.

4. Грабер М. Введение в SQL - М.: Лори, 2008. - 378 с.

5. Аблязов В.И., Редько С.Г. Методические указания по выполнению лабораторных работ - 2008г. 49 с.

6. ДигоС.М. Создание баз данных в среде СУБД Access'2000. Учебное пособие по курсу «Базы данных» 2001 г. Гончаров A. MicrosoftAccess 7.0 в примерах. СПб.: М., 1997. 256с.

7. Гончаров А. Ю. ACCESS 2003. Самоучитель с примерами - М.: КУДИЦ-ОБРАЗ, 2004. - 272 с.

8. Дейт К. Дж. Введение в системы баз данных: Пер. с англ. 7-е изд. М.; СПб.; Киев: Вильяме, 2001. 1071 с.

9. Дженнингс Р. Использование Access 97: Пер. с англ. 2-е спец. изд. М.; Спб.; Киев: Вильяме, 1998. 944 с.

10. Дубнов, П. Ю. Access 2000. Проектирование баз данных / П.Ю. Дубнов. - М. : ДМК, 2000. - 272 с.

11. Информатика: Учебник. /Под ред. Н.В. Макаровой. - М.: Финансы и статистика, 2001.

12. Информационные  технологии (для экономистов):  Учебное пособие/  Под общ.ред. А.К. Волкова. - М.:  ИНФРА-М, 2001.

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