ER-метод логического проектирования баз данных и его реализации в среде СУБД Access

БЕЛКООПСОЮЗ

Учреждение  образования

"Белорусский  торгово-экономический университет  потребительской кооперации"

 

Кафедра информационно-вычислительных систем

КУРСОВАЯ РАБОТА

по дисциплине «Введение  в системы баз данных» на тему:

 «ER-метод логического проектирования баз данных и его реализации в среде СУБД Access»

на примере задачи «Учет нематериальных активов (18-й  вариант)»

 

 

 

 

Выполнил: студент 3-го курса, группы С-32

специальности 1-26 03 01

«Управление информационными ресурсами»

Акушко Д. В.

Научный руководитель: асс. Костюченко Г. Л.

 

 

 

 

 

 

 

Гомель 2010

Содержание

 

 

 

 

 

Введение

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

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

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

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

Задача данной курсовой работы является реализация полученных навыков проектирования БД в ходе учебного процесса.

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

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

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

Курсовая работа изложена на 25 печатных листах.

 

1. Методология проектирования БД.

1.1 Общий обзор проектирования БД

База данных – это организованная структура, предназначенная для хранения информации.

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

Основными целями проектирования БД являются:

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

Три основные фазы проектирования БД:

• концептуальное
• логическое
• физическое

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

При Восходящем подходе работа начинается с самого нижнего уровня — уровня определения  атрибутов (т.е. свойств сущностей), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними.

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

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

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

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

1.2 Методология модели «сущность – связь»

Модель "сущность-связь" (Entity-Relationship model, или ER-модель) представляет собой высокоуровневую концептуальную модель данных, которая была разработана Ченом (Chen) в 1976 году с целью упрощения задачи проектирования баз данных. Данная модель данных представляет собой набор концепций, которые описывают структуру базы данных и связанные с ней транзакции обновления и извлечения данных. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Следует особо подчеркнуть, что концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для реализации базы данных.

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

1. Сущность

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

1.2.2 Атрибуты

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

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

1.2.3 Типы связей

Тип связи (relationship type) является набором ассоциаций между  двумя (или больше) типами сущностей-участников. Каждому типу связи присваивается имя, которое должно описывать его функцию. Как и в случае сущностей, здесь следует различать понятия "связь" и "тип связи". Каждый уникально идентифицируемый экземпляр типа связи мы будем называть просто связью. Связи указывают на отдельные сущности, объединяемые ими.

Охваченные  некоторой связью сущности называются участниками этой связи. Количество участников некоторой связи называется степенью (degree) этой связи. Следовательно, степень связи указывает на количество типов сущностей, охваченных данной связью. Связь со степенью два называется бинарной (binary),  со степенью три - тернарной (ternary), со степенью четыре - кватернарной (quaternary).

Основными двумя  типами накладываемых на связи ограничений являются ее кардинальность (cardinality) и степень участия (participation). Наиболее распространенными являются бинарные связи с показателями кардинальности "один к одному" (1:1), "один ко многим" (1:М) и "многие ко многим" (M:N).

1.3 Методология логического проектирования.

Построение логической модели.

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

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

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

Логический уровень моделирования – это тот, который реально используют многие из сегодняшних разработчиков благодаря доступности на рынке CASE-систем. В отличие от концептуального, логическое моделирование несет в себе сравнительно малую семантическую нагрузку, и часто понимается уже как «логическое моделирование базы данных» (а не прикладной области). В таком понимании цель его состоит в том, чтобы описать базу данных безотносительно к конкретной СУБД и архитектуре БД (считается, что проектируется как бы «логически одна» база данных всей автоматизированной системы). В наиболее распространенном случае (реляционный подход) логическое проектирование сводится к тому, чтобы правильно сформировать объекты, их атрибуты и взаимосвязи с учетом методологических требований ликвидации избыточности, нормализации, целостности и др., а также с учетом требований прикладной постановки и независимости данных (а они могут противоречить друг другу).

 «Академически» в  проекте по разработке ИС правильным  считается создание логической модели БД на стадии анализа, когда за основу можно взять результаты концептуального моделирования прикладной области; результаты логического проектирования БД, в свою очередь, следует использовать при построении физической модели. Практически, однако, концептуальное проектирование часто отсутствует (либо совсем, либо в компьютеризованном виде), а логическая модель испытывает «обратное» воздействие со стороны физической модели, отдельные элементы которой разрабатываются самостоятельно, исходя из соображений эффективности работы СУБД.

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

1.4 Методология физического проектирования. Построение физической модели

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Практическое применение методологий проектирования

2.1 Практическое применение методологии логического проектирования при разработке проекта «Учет нематериальных активов».

Постановка задачи:

К нематериальным активам относят приобретенные  предприятием за плату патенты, технологии, права на использование земельных участков, авторские права, программное обеспечение ЭВМ и др.

В результате проведенного концептуального проектирования БД по учету нематериальных активов было установлено, что в искомой БД должны быть отражены сущности: классификатор "ВИДЫ НЕМАТЕРИАЛЬНЫХ АКТИВОВ" (КодВидНА, НаимВидаНА) и справочники 'НЕМАТЕРИАЛЬНЫЕ АКТИВЫ" (Инвентарный номер, Название нематериальных активов. Балансовая стоимость) и "МАТЕРИАЛЬНО-ОТВЕТСТВЕННЫЕ ЛИЦА" (ШифрМОЛ, ФИОМОЛ). Кроме того, в базе данных должна быть отображена сущность "УЧЕТНАЯ КАРТА", которая основана на документе "Учетная карта нематериальных активов" (табл.1 и табл.2).

Документ "Учетная  карта нематериальных активов" содержит в шапочной части атрибуты: Номер карты. Дата карты. Каждая строка содержательной (табличной) части данного документа содержит атрибуты: Инвентарный номер, Название нематериальных активов, Наименование вида, ФИОМОЛ, Балансовая стоимость.

Между сущностями "НЕМАТЕРИАЛЬНЫЕ АКТИВЫ" и "ВИДЫ НЕМАТЕРИАЛЬНЫХ АКТИВОВ" установлена связь "ПРИНАДЛЕЖАТ", между сущностями "НЕМАТЕРИАЛЬНЫЕ АКТИВЫ" и "УЧЕТНАЯ КАРТА установлена связь "УЧИТЫВЮТСЯ", а между сущностями "МОЛ" и "УЧЕТНАЯ КАРТА" - связь "УПОМИНАЮТСЯ".

Необходимо  учесть следующие обстоятельства (условия  применения):

• номера учетных  карт не повторяются на протяжении всего периода учета;

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

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

• в один день может быть составлено несколько  учетных карт;

• водной карте  могут быть упомянуты несколько  материально-ответственных лиц.

Необходимо  разработать в среде СУБД Access базу данных "Нематериальные активы", в которой должны быть отражены сущности: классификатор «ВИДЫ НЕМАТЕРИАЛЬНЫХ АКТИВОВ» и справочники «МАТЕРИАЛЬНО-ОТВЕТСТВЕННЫЕ ЛИЦА» и «НЕМАТЕРИАЛЬНЫЕ АКТИВЫ». Кроме того, в базе данных должна быть отображена сущность «УЧЕТНАЯ КАРТА», которая основана на документе "Учетная карта нематериальных активов".

Процесс решения  задачи предполагает:

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

-в среде СУБД Access разработку структуры спроектированных таблиц;

-описание схемы данных;

-заполнение таблиц информацией на основе следующих двух учетных карт:

Учетная карта нематериальных активов

№ НА45 от 26.02.2002 г.

Инвентарный номер	Название нематериальных активов	Наименование  вида	ФИО МОЛ	Балансовая  стоимость
ИН057	MS Access-2000	Программы	Гейц Б.	50000 руб.
ИН124	Государственный акт  № ДА 43675	Права на землю	Батый Х.	18000000 руб.
ИН387	Пакет "Тест"	Программы	Лавров С.	20000 руб.

Табл.1. Учетная карта нематериальных активов

 

Учетная карта нематериальных активов

№ НА90 от 03.03.2002 г.

Инвентарный номер	Название нематериальных активов	Наименование  вида	ФИО МОЛ	Балансовая  стоимость
ИН366	MS Excel-2000	Программы	Гейц Б.	30000 руб.
ИН474	20 акций АО "НЕТ"	Акции	Смит А..	7006000 руб.

Табл.2. Учетная карта нематериальных активов

Решение

Документу "Учетная карта нематериальных активов", как и всякому экономическому документу с шапочной и табличной частями, удобно поставить в соответствие две сущности Учетная карта и Строка карты.

Сущность Учетная карта имеет атрибуты, соответствующие реквизитам шапочной части документа: Номер карты и Дата карты. Атрибут Номер карты является ключом сущности Учетная карта.

Сущность Строка карты имеет атрибуты: Инвентарный номер, Название нематериальных активов, Наименование вида, ФИОМОЛ, Балансовая стоимость.

Как и для всякого  экономического документа, можно считать, что между сущностями Учетная карта и Строка карты установлена связь Объединяются. Эта связь имеет показатель кардинальности 1:n, классы принадлежности обеих сущностей являются обязательными. Таким образом, получаем диаграмму ER-экземпляров, приведенную на рис.1.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

При построении диаграммы ER-экземпляров для связи Объединяются мы исходили из того, что:

1. одна шапочная часть учетной карты может объединять несколько строк документа;
2. одна конкретная строка учетной карты может находиться только в одном конкретном документе;
3. не может существовать учетная карта, в которой есть шапочная часть и нет ни одной строки в содержательной части документа;
4. не может существовать учетная карта, в которой есть строка табличной части и отсутствует шапочная часть.

По условию задачи сущности Нематериальные активы и Учетная карта ассоциированы связью Учитываются. Так как мы разделили сущность Учетная карта на две сущности Учетная карта и Строка карты, то необходимо уточнить, с какой из этих двух сущностей связана сущность Нематериальные активы. Ясно, что следует рассматривать связь Учитываются между сущностями Нематериальные активы и Строка карты, т. к. нематериальный актив учитывается именно в табличной части документа. При построении диаграммы ER-экземпляров для связи Учитываются необходимо исходить из того, что:

1. в одной строке учетной карты учитывается только один нематериальный актив;
2. один и тот же нематериальный актив может упоминаться в нескольких строках различных учетных карт;
3. не может существовать строка учетной карты, в которой не упоминается ни один материальный актив;
4. может существовать материальный актив, который не учитывается ни в одной строке учетной карты.

Соответствующая диаграмма  приведена на рисунке 2.

Таким образом, связь Учитываются имеет показатель кардинальности n:1, класс принадлежности сущности Строка карты является обязательным, а класс принадлежности сущности Нематериальные активы – необязательный.

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

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

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

не может существовать строки учетной карты, в которой  не указано какое-либо материально-ответственное  лицо;

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

Соответствующая диаграмма  приведена на рисунке 3.

 

Связь Упоминаются имеет показатель кардинальности 1:n, класс принадлежности сущности Строка карты является обязательным, а класс принадлежности сущности Материально-ответственные лица – необязательный.

При построении диаграммы ER-экземпляров для связи Принадлежат необходимо исходить из того, что:

одному виду нематериальных активов могут принадлежать несколько  объектов нематериальных активов;

один и тот же объект нематериальных активов может принадлежать только одному виду нематериальных активов;

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

не может существовать объекта нематериальных активов, который  не принадлежит ни одному виду нематериальных активов.

Соответствующая диаграмма  приведена на рисунке 4.

Таким образом, связь Принадлежат имеет показатель кардинальности n:1, класс принадлежности сущности Нематериальные активы является обязательным, а класс принадлежности сущности Виды нематериальных активов – необязательный.

Диаграмма ER-типа для проектируемой базы данных приведена на рисунке 5.

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

ВидыНА (КодВидаНА, НаимВидаНА);

НематАктивы (ИнвНомер, НазвНА, КодВидаНА).

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

НематАктивы (ИнвНомер, НазвНА, КодВидаНА).

СтрокаУК (ИнвНомер, ФИОМОЛ, БалСтоим).

На основании того же правила 4 генерации отношений  связь Упоминаются порождает  два отношения по одному для каждой сущности, причем ключевой атрибут ШифрМОЛ сущности Материально-ответственные лица должен быть включен в число атрибутов отношения Строка карты. После включения атрибута ШифрМОЛ наличие атрибута ФИОМОЛ в отношении Строка карты становится избыточным, т. к. значение указанного атрибута однозначно определяется значением атрибута ШифрМОЛ. Получаем следующие отношения:

МОЛ (ШифрМОЛ, ФИОМОЛ);

СтрокаУК (ИнвНомер, ШифрМОЛ, БалСтоим).

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

СтрокаУК (ИнвНомер, НомерУК, ШифрМОЛ, БалСтоим).

Кроме того, к сгенерированным  отношениям добавляется отношение:

УчетнаяКарта (НомерУК, ДатаУК).

Таким образом, получаем следующий набор таблиц БД (ключевые атрибуты выделены полужирным начертанием):

ВидыНА (КодВидаНА, НаимВидаНА);

НематАктивы (ИнвНомер, НазвНА, КодВидаНА);

МОЛ (ШифрМОЛ, ФИОМОЛ);

УчетнаяКарта (НомерУК, ДатаУК);

СтрокаУК (ИнвНомер, НомерУК, ШифрМОЛ, БалСтоим).

Таблицы ВидыНА, НематАктивы  и МОЛ содержат нормативно-справочную информацию, а таблицы УчетнаяКарта и СтрокаУК – оперативно-учетную.

2.2. Практическое применение методологии физического проектирования при разработке проекта «Учет нематериальных активов».

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

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