УДК 681.3
ББК 32.973
В75
Издается по решению «Учебно-методического совета Северо-Казахстанского государственного университета им.М. Козыбаева» (протокол № 2 от 21.10.2005г. )
Рецензенты:
Нач. УМС, к.т.н. Шинтемирова А.У.
Зав. каф. физики, к.ф-м.н. Леонтьев П.И.
Воронов А.В.
В75 Проектирование баз данных: методическое пособие по выполнению лабораторных работ. Петропавловск: СКГУ им. М. Козыбаева, 2005, - 56 с.
Методическое пособие представляет собой лабораторный практикум по предмету «Проектирование баз данных». Оно содержит задания к работам, необходимый теоретический материал и примеры. В пособии рассматриваются процессы логического и физического проектирования. В качестве целевой СУБД используется MS SQL Server 2000.
Для студентов специальностей «Информационные системы» и «Информатика. Может быть использовано при подготовке к лабораторным работам, СРС, СРСП и в дистанционном обучении
УДК 681.3
ББК 32.973
© Воронов А.В., 2005
© СКГУ, 2005
Введение
Данное методическое пособие предназначено для студентов специальностей "Информационные системы в бизнесе, экономике и управлении" и «Информатика» изучающих дисциплину “Проектирование баз данных".
Методическое пособие выполнено в соответствии с государственным стандартом РК и учебным планом специальности "Информационные системы в бизнесе, экономике и управлении" и рассчитано на учебный курс, в котором лабораторные занятия проводятся один раз в неделю. На каждую лабораторную работу отводится 1-2 занятия.
В методическом пособии содержится теоретический и практический материал, необходимый студентам для выполнения лабораторных работ по данному предмету. Пособие разделено на 8 частей, каждая из которых соответствует конкретной лабораторной работе.
Для выполнения лабораторных работ необходимо следующее программное обеспечение:
Построение диаграмм IDEF1X – например Borland Together Designer, ERWin4.0.;
MS SQL Server 2000
Лабораторная работа №1: «Логическое проектирование»
Задание:
Провести анализ предметной области;
Выявить классы пользователей, которые будут работать с проектируемой базой данных;
Для каждого класса пользователей построить концептуальную модель в нотации IDEF1X;
Построить интегрированную концептуальную модель.
Теоретический материал:
Целью логического проектирование является обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Результатом процесса логического проектирования является концептуальная (другое название - инфологическая) модель данных. Данная модель строится по аналогии с естественным языком и не привязана ни к одной СУБД.
Процесс логического проектирования продолжается проектированием физическим, в котором происходит выбор СУБД, в которой будет реализована база данных, и концептуальная модель преобразуется в схему данных в соответствии с требованиями целевой СУБД.
Существует несколько подходов к проведению процесса логического проектирования. Мы будем использовать подход, в котором весь процесс разделяется на этапы анализа требований, моделирования требований и интеграции.
Этап анализа требований проводится с целью определения задач, для которых будет использована проектируемая база данных, объектов, которые потребуются для решения выявленных задач и пользователей, которые будут работать с базой данных. Для достижения поставленных целей проводится системный анализ предметной области, интервьюирование пользователей, чтение документации и т.п.
В результате этапа анализа требований для каждого класса пользователей мы получаем необходимый для их работы набор отношений, определяем атрибуты отношений, проводим нормализацию.
Следующий этап – моделирование требований. На данном этапе для каждого класса пользователей строится концептуальная модель. Далее, на этапе интеграции все построенные модели объединяются в одну. Как правило, процесс интеграции представляет собой объединение моделей пользователей, при этом точками стыковки являются общие для них отношения. Следует учитывать возможность появления аномалий именования, которые могут проявляться одним из следующих образов:
Одни и те же объекты разные у разных пользователей имеют разные имена. Аномалия разрешается путем переименования отношений (или атрибутов).
Разные объекты имеют одинаковые имена в разных пользовательских представлениях. Также разрешается путем переименования.
Отношения, описывающие один и тот же объект, в разных пользовательских требованиях имеют разный набор атрибутов. Аномалия разрешается либо путем определения некоторого общего набора атрибутов, либо путем объединения наборов атрибутов и последующей декомпозиции отношения.
Как правило, подобные аномалии могут возникнуть в том случае, когда с разными пользователями работают разные проектировщики, не взаимодействующие друг с другом. В случае работы согласованной команды подобные либо не возникают, либо разрешаются еще на этапе анализа требований.
Рассмотрим методологию построения концептуальной модели. Наиболее известной является модель «Сущность - Связь» (Entity - Relationship), предложенная П. Ченом в середине 70-х годов XX века. Мы будем использовать нотацию IDEF1X, которая основывается на модели Чена и используется в большинстве программных средств проектирования баз данных.
Модель «сущность-связь» предлагает использовать для создания концептуальной модели три основных блока: сущности, атрибуты и связи. Рассмотрим эти блоки более подробно:
Сущность – представляет собой объект реального мира, информация о котором хранится в базе данных. Сущность изображается в виде прямоугольника. В нотации IDEF1X имя сущности записывается над ее изображением. Сущности могут разделяться на слабые и сильные. Слабая сущность находится в зависимости от какой-либо другой сущности и не может существовать, если не существует эта сущность. На практике сущность является независимой если она может быть уникально идентифицирована без определения ее связей с другими сущностями. Слабые сущности изображаются в виде прямоугольника с закругленными краями.
Атрибут – представляет собой какое-либо свойство объекта. Список атрибутов записывается в текстовом виде и содержится внутри изображения сущности. При этом сущность графически делится на 2 части – верхнюю и нижнюю, разделенные горизонтальной чертой. В верхней части записываются атрибуты, являющиеся первичным ключом. Первичным ключом называется атрибут или группа атрибутов однозначно идентифицирующих экземпляр сущности. Атрибуты, входящие в состав первичного ключа имеют идентификатор (PK). Все остальные атрибуты располагаются в нижней части сущности.
Следует отметить, что возникают ситуации, когда на роль первичного ключа могут претендовать сразу несколько наборов атрибутов. В таких случаях в качестве первичного ключа выбирают наиболее подходящий для решения задач предметной области набор. Остальные претенденты объявляются альтернативными ключами. Они располагаются в нижней части сущности и имеют идентификатор (AKn), где n – некоторое натуральное число.
Еще одной возможностью группировки атрибутов является группировка по признаку принадлежности к инверсному входу. Инверсным входом называется атрибут или набор атрибутов, которые не могут уникально идентифицировать экземпляр сущности, но при этом часто используются для доступа к данным. Такие наборы имеют идентификатор (IEn), где n – натуральное число и, в дальнейшем, используются для построения индексов.
Связь – представляет собой функциональную зависимость между сущностями. При этом допускается связь сущности с самой собой. В нотации IDEF1X связи делятся на следующие разновидности:
Идентифицирующая – если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Дочерняя сущность при этом всегда является слабой, и ее первичный ключ содержит в себе первичный ключ родительской сущности. Данный тип связи изображается в виде сплошной линии, заканчивающейся точкой со стороны дочерней сущности;
Неидентифицирующая – если экземпляр дочерней сущности идентифицируется независимо от родительской сущности. Связь изображается в виде пунктирной линии с точкой на стороне дочерней сущности. Первичный ключ родительской сущности входит в состав неключевых атрибутов дочерней сущности.
Замечание: следует отметить, что в любом случае атрибуты дочерней сущности, связанные с соответствующими атрибутами, входящими в состав первичного ключа родительской сущности, объявляются внешним ключом и имеют идентификатор (FK).
Многие ко многим – данный тип связи используется, если экземпляру одной сущности соответствует несколько экземпляров другой сущности и наоборот. Связь изображается в виде сплошной линии с точками на обоих ее концах.
Категоризация – связь используется, если некоторая сущность определяет целую категорию объектов одного типа. В этом случае создается родительская сущность для определения категории и отдельные дочерние сущности для каждой категории. Общая часть атрибутов помещается в родительскую сущность, а различающиеся наборы атрибутов размещаются в соответствующих дочерних сущностях. В родительской сущности всегда имеется атрибут, позволяющий различать подкатегории (признак разделения на категории). Данный атрибут называется дискриминатором. Связь категоризации изображается следующим образом: от родительской сущности сплошная линия ведет к специальному элементу категоризации изображаемому в виде круга, подчеркнутого одной или двумя линиями (двумя в случае полной категории и одной – в случае неполной). Рядом с элементом категоризации записывается имя атрибута-дискриминатора. От элемента категоризации проводятся сплошные линии к дочерним сущностям. Точки на концах линий не ставятся.
Кроме типа связи в нотации IDEF1X имеют также мощность (иначе называемую кардинальным числом или кардинальностью). Мощность определяется только для идентифицирующих и неидентифицирующих связей и изображается дополнительным символом возле дочерней сущности.
Отсутствие символа – означает мощность 0, 1, или больше (мощность по умолчанию);
P – означает 1 или больше;
Z – означает 0 или 1;
n, где n – некоторое натуральное число, означает ровно n
Как правило, для проектирования баз данных используются специальное программное обеспечение, позволяющее не только строить диаграммы, но и создавать спецификации, генерировать схему данных, создавать различные физические объекты целевых СУБД – такие как представления, сценарии, триггеры. Одним из таких программ является ERWin. Далее рассмотрим пример создания концептуальной модели в среде ERWin 4.0.
После запуска программы ERWin, Вам будет предложено либо создать новую модель, либо открыть уже существующую. Выбрав создание новой модели, мы попадаем в новое диалоговое окно «выбор типа модели». В нем предложено 3 варианта моделей:
Логическая – дальнейшая работа будет происходить только с логической моделью. Физическое проектирование выполняться не будет;
Физическая – выбирается в случае, если целевая СУБД уже определена и проектирование начнется непосредственно с разработки схемы. В данном случае требуется дополнительно выбрать (в раскрывающихся списках) целевую СУБД и ее версию;
Логико-физическая – выбирается в том случае, если будет производиться полный цикл проектирования. Также как и в предыдущем случае требуется выбрать целевую СУБД. Для выполнения лабораторной работы выбираем этот вид моделирования.
После всех описанных выше действий на экране появится основное окно Erwin (рис.1)
Рис. 1: Основное окно ERWin
Данное окно можно условно разделить на несколько основных частей. Наибольшее пространство занимает окно разработки модели, на рисунке оно имеет название «Display1». Окно может содержать несколько вкладок, на каждой из которых может вестись разработка модели. В лабораторной работе, мы можем поместить на вкладке концептуальные модели для различных классов пользователей.
Слева расположен диспетчер объектов, в котором перечислены группы объектов, из которых может состоять модель. Мы будем использовать группы «domains» (домены) и «entities» (сущности). Выбрав некоторый объект из группы, мы можем работать с ним, используя команды контекстного меню.
В верхней части расположено меню и панели инструментов. ERWin обладает богатым набором панелей инструментов, позволяющих выполнять множество разнообразных действий. Следует отметить, что при переключении на физический уровень модели (с помощью раскрывающегося списка на панелях инструментов) пункты меню и некоторые панели инструментов изменятся.
Для построения модели нам необходимо предпринять ряд шагов. Во-первых, размещаем в окне разработки модели сущности, определенные нами в результате анализа требований. Далее, для каждой сущности определяем первичные ключи. Данное действие можно произвести одним из следующих способов:
В группе «Entities» выбрать нужную сущность, раскрыть список входящих в нее объектов и, выбрав Attributes, выполнить команду New контекстного меню. После этого дать имя новому атрибуту и, дважды щелкнув по нему перейти в окно свойств сущности, где необходимо отметить флажок Primary key;
Дважды щелкнуть по изображению сущности в окне разработки модели. Откроется окно свойств сущности. В нем щелкаем по кнопке New и указываем имя атрибута и определяем, к какому домену он будет принадлежать. после этого отмечаем флажок Primary key. Данный способ более нагляден и быстр, поэтому автор предлагает воспользоваться данным способом при выполнении лабораторной работы.
После того, как определены все первичные ключи для всех сущностей, окно разработки модели может выглядеть примерно так (рис.2)
Рис. 2: Окно разработки модели
В качестве примера проектируется база данных, содержащая информацию, используемую некоторой строительной компанией при проведении работ. В базе должны храниться данные о работниках, зданиях и выполняемых (выполненных) работах. Используется один класс пользователей – менеджер компании. Предложено 3 сущности – worker, building и assignment в которых будет храниться необходимая информация. На рис.2 видно, что мы определили в качестве первичных ключей для сущностей worker и building коды работника и здания соответственно.
Сущность assignment пока не имеет первичных ключей. Это связано с тем, что данная сущность является слабой и будет идентифицирована через первичные ключи 2-х других сущностей.
Следующим шагом в создании логической модели является установление связей между сущностями. Для этого мы выбираем на панели инструментов кнопку с нужным видом связи и производим два щелчка левой кнопкой мыши – вначале по родительской сущности, а потом по дочерней.
На рис.3 показана модель рассматриваемого примера после установления связей.
Рис. 3: Установка связей между сущностями
Нетрудно заметить, что были использованы идентифицирующие связи между сущностью assignment и сущностями worker и building. В результате проведения этого типа связи, изображение сущности изменяется (на изображение слабой сущности) и в нем автоматически появляются первичные ключи wrkr_id и bldg_id (т.к. слабая сущность идентифицируется через сои родительские сущности). Следует отметить, что эти же атрибуты одновременно являются и внешними ключами для связи с родительскими отношениями, что отображено идентификаторами (FK). В случае неидентифицирующей связи мы бы увидели внешние ключи в разделе неключевых атрибутов сущности. Т.о., ERWin автоматически обеспечивает ссылочную целостность по внешним ключам.
Последним шагом создания модели является добавление неключевых атрибутов сущностей. Это можно выполнить аналогично тому, как мы создавали первичные ключи (с той разницей, что не требуется отмечать флажок primary key). На рис.4 изображен окончательный вид логической модели, рассматриваемой в модели.
Рис. 4: Окончательный вид модели
После того, как логическое моделирование завершено, начинаем процесс физического моделирования. В ERWin для переключения на физическую модель выбираем значение “Phisical” в раскрывающемся списке на панели инструментов.