Методическое пособие по выполнению курсовой работы (проекта) по междисциплинарному курсу мдк 04. 01 «Технология разработки и защиты базы данных»
Основная часть пояснительной записки
жүктеу/скачать 380,1 Kb.
|
6de276100d4c3cb0
- Бұл бет үшін навигация:
- 1.2.5.1 Проектирование базы данных
1.2.5 Основная часть пояснительной запискиВ главах основной части работы подробно рассматриваются и обобщаются результаты исследования. Содержание глав основной части должно точно соответствовать теме работы и полностью её раскрывать. Эти главы должны показать умение автора сжато, логично и аргументирование излагать материал. Все материалы, не являющиеся необходимыми для решения поставленной в работе задачи, выносятся в приложения. В основной части должны быть отражены следующие этапы курсового проектирования: При выполнении курсового проекта следует придерживаться следующего порядка этапов проектирования: Содержание Введение Проектирование базы данных Анализ и описание предметной области информационной системы Проектирование концептуальной модели Построение логической модели, схемы базы данных Выбор СУБД Реализация базы данных Физическое проектирование Написание исходного кода БД Написание запросов, функций и хранимых процедур Заключение Итак, основная часть пояснительной записки должна включать следующие разделы: 1.2.5.1 Проектирование базы данныхБаза данных и система управления базой данных являются неотъемлемой частью информационных систем предприятия. Процесс проектирования базы данных представляет собой последовательность переходов от словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. 1.2.5.1.1 Анализ и описание предметной области информационной системы Начните анализ предметной области информационной системы с общего описания предприятия, его области деятельности. Необходимо кратко перечислить основные бизнес-процессы, которые реализуются на предприятии. Бизнес-процесс – последовательность действий, направленных на получение заданного результата, ценного для организации. Далее необходимо выделить один бизнес-процесс, для автоматизации которого в рамках курсовой работы будет спроектирована и реализована база данных. Затем необходимо изучить пользовательские информационные потребности: выделить основных пользователей базы данных и кратко описать их функции в рамках выделенного бизнес-процесса. Необходимо описать входные документы, которые являются основанием для заполнения базы данных. Необходимо описать выходные документы, которые должны создаваться на основе данных, хранящихся в базе данных. Сформулируйте бизнес-правила, которые будут основой для задания ограничений при проектировании и реализации базы данных, а также для обеспечения пользовательского интерфейса в процессе реализации базы данных. Бизнес-правила – факты, ограничения, которые должны выполняться в ходе бизнеспроцесса, сформулированные на естественном языке. На основании полученной информации сформулируйте основные задачи, которые будет решать база данных в информационной системе. Системный анализ и словесное описание информационных объектов предметной области должны заканчиваться подробным описанием предметной области, которая требуется для решения конкретных задач, и которая должна храниться в БД. Необходимо перечислить объекты предметной области ИС, их атрибуты, описать домены атрибутов. Этапы проектирования базы данных Процесс проектирования включает в себя следующие этапы. Концептуальное проектирование – это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации. Логическое проектирование – это процесс конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации. Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным. 1.2.5.1.2 Проектирование концептуальной модели Необходимо перечислить классические и современные модели данных, выбрать модель данных, обосновать свой выбор. Концептуальное проектирование Основными задачами концептуального проектирования являются определение предметной области системы и формирование взгляда на ПО с позиций сообщества будущих пользователей БД, т. е. инфологической модели ПО. Концептуальная модель ПО представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей в терминах, понятных пользователю и не зависимых от реализации БД. Это описание выражается в терминах не отдельных объектов ПО и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу предметной области из одного состояния в другое. Рассмотрим основные подходы к созданию концептуальной модели предметной области. Функциональный подход к проектированию БД. Этот метод реализует принцип "от задач" и применяется тогда, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД. Предметный подход к проектированию БД. Предметный подход к проектированию БД применяется в тех случаях, когда у разработчиков есть чёткое представление о самой 6 ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена или определена не полностью. Тогда основное внимание уделяется исследованию ПО и наиболее адекватному её отображению в БД с учётом самого широкого спектра информационных запросов к ней. Проектирование с использованием метода «сущность-связь» Метод "сущность–связь" (entity–relation, ER–method) является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает её на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, затем они объединяются. Выбор локального представления зависит от масштабов ПО. Обычно она разбивается на локальные области таким образом, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6 - 7 сущностей. Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ). Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств. Типы сущностей можно классифицировать как сильные и слабые. Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных. Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – слабая, которая зависит от наличия соответствующего читателя. Слабые сущности называют подчинёнными (дочерними), а сильные – базовыми (основными, родительскими). Для каждой сущности выбираются свойства (атрибуты). Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными 7 ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности. Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута. Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности). Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты). Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности – множества значений (или домена), которые может принимать данный атрибут. Далее осуществляется спецификация связей внутри локального представления. Связи могут иметь различный содержательный смысл (семантику). Различают связи типа «сущность – сущность», «сущность - атрибут» и «атрибут - атрибут» для отношений между атрибутами, которые характеризуют одну и ту же сущность или одну и ту же связь типа «сущность – сущность» Каждая связь характеризуется именем, обязательностью, типом и степенью. Различают факультативные и обязательные связи. Если вновь порождённый объект одного типа оказывается по необходимости связанным с объектом другого типа, то между этими типами 8 объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной. По типу различают множественные связи «один к одному» (1:1), «один ко многим» (1:N) и «многие ко многим» (M:N). Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нём работают. Примером тернарной связи является связь типа экзамен между сущностями ДИСЦИПЛИНА, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ. Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рисунке Рисунок 1 - Пример ER–диаграммы с однозначными и многозначными атрибутами жүктеу/скачать 380,1 Kb. Достарыңызбен бөлісу:
|