Новая методичка кур раб по БД (1). Методические указания к курсовой работе по дисциплине Базы данных Составитель А. Б. Градусов
 Скачать 239.4 Kb.
|
|
Министерство образования и науки РФ Государственное образовательное учреждение высшего образования «Владимирский государственный университет имени Александра Григорьевича и Николая Григорьевича Столетовых» (ВлГУ) Кафедра вычислительной техники и систем управления Методические указания к курсовой работепо дисциплине «Базы данных»Составитель:А.Б. ГрадусовВладимир 2018 УДК 004.65Рецензентдоктор технических наук, профессор зав. кафедрой «Информационные системы и программная инженерия» ВлГУ И.Е. Жигалов  Методические указания к курсовой работе по дисциплине «Базы данных» / Владим. гос. ун-т ; сост.: А. Б. Градусов. – Владимир: Изд-во Вадим. гос. ун-та, 2018. – 44 с.Изложен порядок выполнения курсовой работы по дисциплине «Базы данных». Рассматриваются особенности инфологического проектирования баз данных и построения реляционной модели. Приведены варианты заданий к курсовой работе. Предназначены для студентов направления подготовки 09.03.03 «Прикладная информатика». ВВЕДЕНИЕСовременные информационные системы, основанные на концепции баз данных, обеспечивают долговременное хранение и обработку больших объемов информации, имеющих сложную структуру. Проектирование базы данных (БД) является одной из наиболее сложных и ответственных задач, связанных с созданием информационных систем. Методология проектирования баз данных может рассматриваться как совокупность методов и средств, последовательное применение которых обеспечивает разработку проекта баз данных, удовлетворяющего заданным целям. Для создания баз данных и модификации данных разработано специальное программное обеспечение, называемое системами управления базами данных(СУБД). Главная роль СУБД заключается в обеспечении пользователей инструментом, позволяющим оперировать данными в абстрактных терминах, не связанными со способами их хранения в компьютере. СУБД также предоставляет язык определения данных, описывающий базу данных в терминах некоторой модели. В настоящее время большинство СУБД используют реляционную модель данных, которую предложил в 1970 году Е.Ф. Кодд (Codd). Основная идея состоит в том, что данные нужно связывать в соответствии с их внутренними логическими взаимоотношениями, а не физическими указателями. Таким образом, пользователи могут комбинировать данные из разных источников, если логическая информация, необходимая для этого, присутствует в источниках данных. При проектировании реляционной БД существует проблема выбора из множества вариантов набора реляционных таблиц, обеспечивающего корректное представление предметной области. Основными критериями для выбора таблиц являются: возможность хранения всех необходимых данных в БД; исключение избыточности БД; непротиворечивость БД при обновлении, удалении и включении данных. В методических указаниях приводятся сведения об информационных моделях, основных этапах и методах проектирования БД на основе диаграммы сущность – связь. Выполнение курсовой работы является заключительным этапом обучения студентов по дисциплине «Базы данных» и имеет своей целью систематизацию, закрепление и расширение теоретических знаний и получение практических навыков при решении конкретных задач, связанных с созданием баз данных, развитие творческих навыков при самостоятельном решении задач. Во время выполнения курсовой работы студент должен показать умение использовать теоретические знания, накопленные в результате изучения всех предшествующих дисциплин, и освоить в короткий срок методы проектирования баз данных. 1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ 1.1 Стадии и этапы разработки баз данных Процесс разработки БД – это итеративный процесс, в ходе которого обычно приходится многократно возвращаться к предыдущим этапам выполнения работы, вносить необходимые изменения и затем заново повторять последующие этапы до достижения необходимого результата. Процесс разработки базы данных можно разбить на две стадии: 1. Проектирование базы данных. 2. Программная реализация базы данных. Стадия проектирования БД включает следующие основные этапы: 1. Обследование предметной области. 2. Инфологическое проектирование (разработка инфологической модели предметной области). 3. Даталогическое проектирование. В БД хранится информация об определенной предметной области. Предметной областью называется часть реального мира, представляющая интерес для данного исследования (использования) и отражаемая в базе данных. Для формирования представления о данных, их составе и использовании в конкретных условиях служат информационные модели (ИМ). При решении конкретных задач реальная действительность воспроизводится с существенными ограничениями, зависящими от области деятельности, поставленных целей. Значит, для создания БД надо сначала проанализировать предметную область и создать её информационную модель. Основой для анализа предметной области служат документы, которые ее отражают, и информация, которую можно получить от специалистов этой предметной области в процессе общения с ними. Для анализа берутся те документы, которые имеют отношение к решаемой задаче. Изучение документов позволяет выявить объекты и их свойства, информацию о которых необходимо хранить в БД. Из общения со специалистами необходимо извлечь сведения об особенностях предметной области, которые позволяют установить ограничения целостности, зависимости и связи между объектами (субъектами) предметной области. Модель предметной области может быть описана любым удобным для разработчика способом (словесное описание, набор формул, диаграмма потоков данных и т.п.). При проектировании баз данных используется диаграмма «сущность–связь» (ER–диаграммы (entity-relation diagram)). На следующем этапе – этапе даталогического проектирования – ER-диаграмма формальным способом преобразуется в схему реляционной базы данных (БД). На основании схемы БД и описания сущностей предметной области составляются таблицы (отношения) базы данных. Потом выполняется нормализация отношений. Это необходимо сделать для того, чтобы исключить нарушения логической целостности данных и повысить, таким образом, надёжность и достоверность данных. В результате всех этих операций создаётся схема БД – основной документ для базы данных. Программная реализация базы данных На этом этапе полученная схема базы данных описывается на языке DDL (Data definition language) – языке определения данных, который поддерживается выбранной СУБД. Стадия программной реализации БД содержит работы: 1. Создание таблиц. 2. Создание межтабличных связей (для поддержки целостности данных). 3. Разработку процедур обработки данных (написание текста создания вспомогательных объектов базы данных (представления, хранимые процедуры, триггеры и т.д.)). 4. Отладку БД. 5. Тестирование БД (выполнение контрольных примеров). 6. Разработка эксплуатационной документации БД. Если пользователей базы данных можно разделить на группы по характеру решаемых задач, то для каждой группы создаётся свой набор прав доступа к объектам БД. 1.2. Последовательность проектирования базы данных Процесс проектирования базы данных включает в себя следующие шаги: 1. Определение задач, стоящих перед базой данных. 2. Сбор и анализ документов, относящихся к исследуемой предметной области. 3. Описание особенностей предметной области, которые позволяют установить зависимости и связи между объектами предметной области. 4. Создание модели предметной области. 5. Определение групп пользователей и перечня задач, стоящих перед каждой группой. 6. Выбор СУБД (системы управления базой данных). 7. Создание логической схемы БД. 8. Создание схем таблиц, определение типов данных атрибутов и ограничений целостности. 9. Нормализация отношений (до третьей или четвёртой нормальной формы). 10. Определение прав доступа пользователей к объектам БД. 11. Написание текста создания основных объектов базы данных на языке SQL в синтаксисе выбранной СУБД (пользователи, таблицы и др.). 12. Написание текста создания вспомогательных объектов базы данных (представления, хранимые процедуры, триггеры, роли и т.д.). Эти шаги можно объединить в 4 этапа: 1. Инфологическое проектирование (1-5). 2. Выбор системы управления базой данных (СУБД) и других инструментальных программных средств (6). 3. Логическое проектирование БД (7-10). 4. Программная реализация базы данных (11-12). На сегодняшний день не существует формальных способов моделирования реальности, но инфологический подход закладывает основы методологии проектирования базы данных как модели предметной области. 1.3 Инфологическое проектирование Цель инфологического проектирования - построение независимой от СУБД информационной структуры путем объединения информационных требований пользователей. Результатом этого этапа является представление информационных требований в виде диаграмм «сущность-связь». Основными задачами этапа инфологического проектирования являются определение предметной области системы и формирование взгляда на неё с позиций сообщества будущих пользователей БД, т.е. информационно-логической модели предметной области. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Сущность – это реальный объект предметной области, о котором в системе будут накапливаться данные. Сущности представляют собой объекты, которые пользователи считают важными в моделируемой предметной области. Примерами сущностей могут быть люди, автомобили, дома, книги, компании, штатное расписание. На диаграммах «сущность – связь» сущности представляют в виде прямоугольника, содержащего внутри название. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Иваново и т.д. Каждая сущность обладает определенными свойствами. Например, у человека есть имя, дата рождения, вес, рост. Атрибут – поименованная характеристика (свойство) сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Атрибуты на диаграмме «сущность-связь» изображаются в виде овалов, прикрепленных к соответствующей сущности (рис. 1).  Рисунок. 1. Представление сущности и ее атрибутов Важно понимать, что сущности нужно в концептуальном плане отделять от атрибутов, которые их описывают, т.к. значения атрибутов могут меняться, в то время как описываемый ими объект остается прежним. Например, у человека может измениться рост, вес, семейное положение, но это будет тот же самый человек. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности. Ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Например, для сущности ЧЕЛОВЕК ключом является атрибут Номер страхового свидетельства или набор атрибутов имя, дата рождения. На диаграммах сущность – связь ключ подчеркивают одинарной сплошной линией (рис. 1). Часто в качестве ключей применяют так называемые суррогатные ключи. Это искусственно сформированные внутренние номера без смысла вне базы данных, которые однозначно определяют элемент сущности. Использование суррогатных ключей предпочтительнее по сравнению с использованием составных ключей, так как уменьшается вероятность нарушения целостности данных из-за ошибок в одном из атрибутов. Две и более сущности могут быть связаны между собой отношением. Связь это ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей. Связь устанавливается между экземплярами сущностей, а не их типами. Например, для сущностей КЛИЕНТ и ЗАКАЗ связь устанавливается между конкретным клиентом и его заказами. Для связывания экземпляров сущностей используются их уникальные идентификаторы экземпляров сущности (ключи). Графически связи между двумя сущностями представляется в виде соединяющего их отрезка, дополненного ромбом. Существуют две важные характеристики связей: показатель кардинальности между сущностями и класс принадлежности сущностей. Показатель кардинальности – это число экземпляров одной сущности, связанных с одним экземпляром другой сущности. В зависимости от показателя кардинальности различают следующие типы бинарных связей: - один – к – одному (1:1) (one-to-one relationship); - один – ко – многим (1:М) (one-to-many relationship); - многие – ко – многим (М:М) (many – to – many relationship). Класс принадлежности – признак, определяющий обязательность участие экземпляров сущности в некоторой связи. Класс принадлежности называется обязательным, если все экземпляры данной сущности должны участвовать в некоторой связи. В таблице 1 приведены обозначения связей с различными характеристиками. Таблица 1
Примеры связей с различными показателями кардинальности и классами принадлежности приведены на рис. 2 .   Рисунок 2. Примеры связей Каждый экземпляр сущности ЖЕНАТЫЙ МУЖЧИНА должен быть обязательно связан с одним экземпляром сущности ЗАМУЖНЯЯ ЖЕНЩИНА, т.е. класс принадлежности с обеих сторон обязательный, а показатель кардинальности – один к одному (1:1). Предполагается, что один инспектор может контролировать несколько рабочих, а каждого рабочего контролирует только один инспектор. Такая связь будет иметь показатель кардинальности один-ко-многим (1:М). Класс принадлежности с обеих сторон обязательный, т.к. все ИНСПЕКТОРА занимаются контролем, а все РАБОЧИЕ контролируются. В случае сущностей АВТОМОБИЛЬ и АЗС показатель кардинальности много-ко-многим (М:М). Каждый Автомобиль может заправиться на разных АЗС, а на одной АЗС могут заправляться разные АВТОМОБИЛИ. Класс принадлежности со стороны сущности АЗС необязательный, т.к. АЗС может быть закрыта на ремонт, следовательно, на этой АЗС не может заправиться ни один автомобиль, т.е. с этой АЗС не будет связан ни один экземпляр сущности АВТОМОБИЛЬ. | |||||||||||
