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 Методология физического проектирования. Построение физической модели

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

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

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