Лабораторная работа создание баз данных. Лабораторная работа проектирование базы данных
 Скачать 1.01 Mb.
|
|
ЛАБОРАТОРНАЯ РАБОТА 1. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ Цель: спроектировать БД для выбранной предметной области согласно примеру, представленном в методическом указании. Провести нормализацию (до 3 нормальной формы). ЗАДАНИЕ 1) Описать предметную область 2) Выделить ключевые объекты системы 3) Провести инфологическое проектирование a. Составить и прокомментировать ER-диаграмму b. Составить и прокомментировать уточненную ER-диаграмму (с атрибутами) 4) Провести логическое проектирование 5) Провести нормализацию (до 3 нормальной формы) 6) Описать ключевые ограничения Примечание: Для проектирования рекомендуется использовать приложение Oracle SQL Developer Data Modeler ( http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html ) или Astah Professional ( http://astah.net/features/er-diagram ). Также вы можете осуществить проектирование при помощи векторного графического редактора, редактора диаграмм и блок-схем – Microsoft Visio. Детальное описание установки редактора вы можете найти в данном методическом указании. После нормализации количество таблиц должно не превышать 7, желательно 5 таблиц. ХОД РАБОТЫ 1. Выбрать вариант задания 2. Провести инфологическое проектирование проанализировав предметную область согласно варианту задания. Разработать ER-диаграмму сущностей 3. Осуществить процесс логического проектирования, подробно расписав процесс преобразования ER-диаграммы в схему отношений. Учитывая знания, полученные по нормализации отношений. 4. Провести нормализацию схемы, полученной в результате выполнения лабораторной работы. В результате у Вас должны получиться схемы отношений, представленные в табличном виде (как в примере таблицы с 1.8 по 1.17). 5. Подготовить отчет о проделанной работе. Структура отчета: титульный лист; задание; описание процесса проектирования (инфологическое проектирование и ER-модель, аналогично примеру, представленному в данном методическому указании.); заключение; Номер варианта задания определяется по последним двум цифрам номера зачетной книжки. Если образуемое ими число больше 24, то следует взять сумму этих цифр ВАРИАНТЫ ЗАДАНИЙ 1 музей; 2 минимаркет; 3 поликлиника; 4 пиццерия; 5 прокат; 6 гостиница; 7 документооборот; 8 строительная компания; 9 спортивный клуб; 10 завод по изготовлению автомобильных деталей; 11 транспортная компания; 12 туристическая компания; 13 картинная галерея; 14 товары-почтой; 15 автомастерская; 16 книжный склад; 17 авиакомпания; 18 аудио коллекция; 19 компания по сбыту лекарственных препаратов; 20 фирма по ремонту; 21 касса театра. 22 кулинария; 23 деканат; 24 поликлиника; ОГЛАВЛЕНИЕ ЗАДАНИЕ ................................................................................................................................................. 1 ХОД РАБОТЫ .......................................................................................................................................... 1 ВАРИАНТЫ ЗАДАНИЙ .......................................................................................................................... 2 1. КРАТКАЯ ТЕОРИЯ ............................................................................................................................ 4 1.1. Основные понятия ....................................................................................................................... 5 1.2. Этапы проектирования базы данных: ....................................................................................... 7 1.3. Инфологическое проектирование .............................................................................................. 7 1.3.1. Entity-Relationship Diagrams ............................................................................................... 8 1.3.2. Логическое проектирование ............................................................................................... 9 1.3.3. Физическое проектирование ............................................................................................ 10 1.4. Пример проектирования реляционной базы данных ............................................................. 10 1.4.1. Инфологическое проектирование .................................................................................... 10 1.4.2. Логическое проектирование реляционной БД ............................................................... 12 1.5. Нормализация полученных отношений (до 3НФ) ................................................................. 19 1.5.1. Первая нормальная форма ................................................................................................ 19 1.5.2. Вторая нормальная форма ................................................................................................ 19 1.5.3. Третья нормальная форма ................................................................................................ 20 1.6. Нормализация отношений для БД «Издательская компания». ............................................. 21 1.1.1. 1 НФ (нормальная форма) ................................................................................................ 21 1.6.1. 2 НФ (нормальная форма) ................................................................................................ 22 1.6.2. 3 НФ (нормальная форма) ................................................................................................ 22 1.6.3. Окончательные схемы отношений .................................................................................. 24 1.7. Пример нормализации отношение №3 .................................................................................... 26 1.7.1. 1 НФ (нормальная форма) ................................................................................................ 26 1.7.2. Определение функциональной зависимости .................................................................. 27 1.7.3. 2 НФ (нормальная форма) ................................................................................................ 27 1.7.4. 3НФ (нормальная форма) ................................................................................................. 29 1.7.5. Вывод.................................................................................................................................. 30 1.7.6. Определение дополнительных ограничений целостности ............................................ 30 2. ЗАКЛЮЧЕНИЕ ................................................................................................................................ 31 1. КРАТКАЯ ТЕОРИЯ Перед созданием базы данных разработчик должен определить, из каких таблиц должна состоять база данных, какие данные нужно поместить в каждую таблицу, как связать таблицы. Эти вопросы решаются на этапе проектирования базы данных. В результате проектирования должна быть определена логическая структура базы данных, то есть состав реляционных таблиц, их структура и межтабличные связи. Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определить все необходимые источники информации для удовлетворения предполагаемых запросов пользователей и определить потребности в обработке данных. На основе такого описания на этапе проектирования базы данных определяются состав и структура данных предметной области, которые должны находиться в БД и обеспечивать выполнение необходимых запросов и задач пользователей. Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база данных. 1.1. Основные понятия Понятие реляционный (англ. Relation – отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd). Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами: каждый элемент таблицы – один элемент данных; все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.); каждый столбец имеет уникальное имя; одинаковые строки в таблице отсутствуют; порядок следования строк и столбцов может быть произвольным. Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение. Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации как показано на рисунке 1.1. СОТР_НОМЕР СОТР_ИМЯ СОТР_ЗАРП СОТР_ОТД_НОМЕР 2934 Иванов 112 000 310 2935 Петров 144 000 310 2936 Сидоров 92 000 313 2937 Федоров 110 000 310 2938 Иванова 112 000 315 Отношение сотрудники Кортежи Атрибуты Номера пропусков Имена Размер выплат Номера отделов Первичный ключ Домены Целые числа Строки символов Деньги Целые числа Типы данных Рисунок 1.1 – Схема реляционного отношения Тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена. Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в схеме, показанной выше, определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака). Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа. Отношение – это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой. В свою очередь отношения имеют два важных свойства: арность – число атрибутов в отношении; мощность – это кардинальное число отношения, т.е. число кортежей (строк) в отношении. Каждое реляционное отношение соответствует одной сущности (объекту предметной области) и в него вносятся все атрибуты сущности. Для каждого отношения необходимо определить первичный ключ и внешние ключи. Ключ или потенциальный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно выбрать требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность должна, но не обязана обладать хотя бы одним возможным ключом. Другими словами ключ – это поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальным, то есть в таблице не должно существовать двух ил более записей с одинаковым значением первичного ключа. Первичные ключи облегчают установление связей между таблицами. Поскольку первичный ключ должен быть уникальным, для него могут использоваться не все поля таблицы. В том случае, если базовое отношение не имеет потенциальных ключей, вводится суррогатный первичный ключ, который не несёт смысловой нагрузки и служит только для идентификации записей (например ID записи). Примечание: суррогатный первичный ключ также может вводиться в тех случаях, когда потенциальный ключ имеет большой размер (например, длинная символьная строка) или является составным (не менее трёх атрибутов). Потенциальными ключами отношения АВТОРЫ являются атрибуты Паспортные данные и ИНН. Первый хранится как длинная строка, а последний по условиям предметной области не является обязательным. Поэтому для авторов необходимо ввести суррогатный ключ – A_id. Книги можно идентифицировать по атрибуту Контракт: его номер обязателен и уникален. Потенциальные ключи отношения СОТРУДНИКИ – атрибуты ИНН, Паспортные данные, Табельный номер, причём все они обязательные. Табельный номер занимает меньше памяти, чем ИНН, поэтому он и будет первичным ключом. Кортежи отношения ЗАКАЗЫ можно идентифицировать ключом Номер заказа. Потенциальными ключами вспомогательных отношений являются комбинации первичных ключей соответствующих базовых отношений. Отношения приведены в таблице 1.1-1.7. Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N – числовой, C – символьный, D – дата (последний имеет стандартную длину, зависящую от СУБД, поэтому она не указывается). 1.2. Этапы проектирования базы данных: инфологическое проектирование; определение требований к операционной обстановке, в которой будет функционировать информационная система; выбор системы управления базой данных (СУБД) и других инструментальных программных средств; логическое проектирование БД; физическое проектирование БД. 1.3. Инфологическое проектирование Инфологическое проектирование – построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создается без ориентации на какую-либо конкретную СУБД и модель данных. Конкретный вид и содержание концептуальной модели базы данных определяется выбранными для этого формальным аппаратом. Обычно используют графические нотации, подобные ER- диаграммам. Чаще всего инфологическая (концептуальная) модель базы данных включает в себя: описание информационных объектов или понятий предметной области и связей между ними; описание ограничений целостности, то есть требований к допустимым значениям данных и к связям между ними. Пример инфологического проектирования показан на рисунке 1. Рисунок 1 – Инфологическая модель Entity-Relationship Diagrams Имеется целый ряд методик создания информационно-логических моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют «объект – отношение» либо «сущность – связь». Модель ERD была предложена Питером Пин Шен Ченом в 1976 г. К настоящему времени разработано несколько ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом. Диаграммы конструируются из небольшого числа компонентов. Благодаря наглядности представления они широко используются в CASE-средствах (Computer Aided Software Engineering). Рассмотрим используемую терминологию и обозначения. Сущность (Entity) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа (сущности). Каждая сущность должна обладать некоторыми свойствами: иметь уникальное имя; причем к этому имени должна всегда применяться одна и та же интерпретация (определение сущности). И наоборот: одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами; обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются ею через связь; обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Одна из участвующих в связи сущностей – независимая, называется родительской сущностью, другая – зависимая, называется дочерней или сущностью-потомком. Как правило, каждый экземпляр родительской сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров дочерней сущности. Каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности- потомка может существовать только при существовании сущности-родителя. Связи дается имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. |