Заключение

В настоящей статье мы рассмотрели жизненный цикл информационных систем и убедились, что проектирование данных играет в нем ключевую роль. Мы также узнали, что представляют собой процессы логического (концептуального) и физического моделирования данных.

Помимо этого мы рассмотрели несколько наиболее популярных средств проектирования данных— как специализированных, так и входящих в состав комплексных CASE-средств. Изучение возможностей этих продуктов свидетельствует о том, что все они, обладая своими особенностями и имея в определенной степени различающиеся сферы применения, как правило, имеют и сходные черты, в число которых входят:

1. Поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе.

2. Поддержка нескольких типов СУБД, включая не только серверные, но и настольные.

3. Поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных).

4. Способность осуществлять обратное проектирование на основе либо имеющейся базы данных, либо имеющегося DDL-скрипта.

5. Возможность генерации отчетов и проектной документации на основе созданной модели.

6. Возможность сохранения модели в репозитарии, который во многих случаях может быть разделяемым.

7. Поддержка генерации кода для одного или нескольких средств разработки или языков программирования. Следует отметить, что в этом отношении самым популярным средством разработки является, по-видимому, Visual Basic.

Рассмотрев процесс проектирования данных и средства, с помощью которых можно его осуществить, мы можем приступить к изучению следующего этапа жизненного цикла информационных систем — разработке клиентских приложений. Именно ей и будет посвящена следующая статья данного цикла.

 

Создание Логической модели бд в Visio

Лабораторная работа № 2. Логическая модель базы данных

Логическая модель – графическое представление структуры базы данных с учетом принимаемой модели данных (иерархической, сетевой, реляционной и т.д.), независимое от конечной реализации базы данных и аппаратной платформы. Иными словами, она показывает, ЧТО хранится в базе данных (объекты предметной области, их атрибуты и связи между ними), но не отвечает на вопрос КАК (рис. 1).

Описание предметной области:

Оптовый заводской склад

На склад поставляются детали, выполненные из определенных материалов (литые), от заданного круга поставщиков (постоянных или случайных) из различных городов.

В качестве поставщиков могут выступать юридические лица и индивидуальные предприниматели, причем эти группы описываются своим набором характеризующих атрибутов; юридические лица – номер и дата гос. регистрации, наименование, юридический адрес, форма собственности; предприниматели – ИНН, ФИО, страховой полис, номер паспорта, дата рождения.

При оформлении поставки учитываются дата, количество и стоимость, вид упаковки и способ доставки (автотранспорт, ж/д транспорт, самовывоз), причем одна поставка может включать несколько видов деталей.

Поставщики переходят в разряд постоянных, если они совершили поставок на сумму свыше 1 000 000 рублей в год.

Осуществляется отпуск деталей в цеха завода с учетом даты, количества и номера цеха. Поддерживается актуальное количество товаров на складе.

Таблица 1. Роли пользователей и их функции
Роль	Функции
Менеджер	Ведение базы деталей, материалов, поставщиков
Инженер завода	Просмотр спецификаций деталей
Бухгалтер	Оплата поставок
Учетчик	Оформление поставки
Логист	Управление отпуском деталей в цеха завода

  Рис. 1. Логическая модель базы данных в нотации IDEF1X

Методология IDEF1X – один из подходов к моделированию данных, основанный на концепции "сущность – связь" (Entity – Relationship), предложенной Питером Ченом в 1976 г.

Таблица 2.1. Основные элементы нотации IDEF1X
Сущность(Entity)	Графическое изображение
Независимая сущность	Наименование Уникальный идентификатор Атрибуты
Зависимая сущность	Наименование Ссылка на идентификатор (FK) Атрибуты
Связь(Relationship)	Графическое изображение
Неидентифицирующая связь
Идентифицирующая связь	Независ.
Связь «Многие ко многим»
Наследование (обобщение)   Полное    Неполное	Родительск. -й

Независимая сущность – это сущность, уникальный идентификатор которой не наследуется из других сущностей. Изображается в виде прямоугольника с прямыми краями.

Зависимая сущность– это сущность, уникальный идентификатор которой включает по меньшей мере одну связь с другой сущностью. Например, строка документа не может существовать без самого документа (зависит от него). Изображается в виде прямоугольника с закругленными краями.

 

Методология IDEF1X ориентирована на проектирование реляционных моделей баз данных. В основе реляционной модели лежит понятие нормализованного отношения (таблицы). При этом сущности предметной области отображаются в таблицы базы данных (рис. 2), обладающие следующими свойствами:

§ нет одинаковых кортежей (строк), они различаются по уникальному идентификатору – первичному ключу;

§ кортежи (строки / записи) не упорядочены сверху вниз;

§ атрибуты (столбцы) не упорядочены слева направо; в операциях с таблицей ее строки и столбцы могут просматриваться в любой последовательности безотносительно их содержания и смысла;

§   все значения атрибутов – скаляры и имеют одинаковую природу (построены на одном домене).

Рис.

2. Таблица реляционной базы данных

Ключ - столбец или группа столбцов, значения которых однозначно идентифицируют каждую строку.

В одной таблице может быть несколько ключей: один первичный, посредством которого осуществляется связывание отношений, а другие – альтернативные. Свойства ключа:

§ уникальность (не может быть строк с одинаковым ключом);

§ неизбыточность (удаление любого атрибута из ключа лишает его свойства уникальности).

Реляционная база данных− это множество связанных между собой отношений. Связи задаются с помощью вторичных ключей (Foreign key – FK), т.е. атрибутов, которые в других отношениях являются первичными ключами (Primary key – PK).

Основные ограничения целостности реляционной модели:

§ атрибуты из первичного ключа не могут принимать неопределенное значение (целостность объектов);

§ вторичные ключи не могут принимать значения, которых нет среди значений первичных ключей связанной таблицы: если отношение R2 имеет среди своих атрибутов какой-то внешний ключ (FK), который соответствует первичному ключу (PK) отношения R1, то каждое значение FK должно быть равно одному из значений PK.

Создание Логической модели БД в Visio

Чтобы создать Логическую модель базы данных в Visio 2013, выберите Категорию шаблонов «Программы и базы данных», а в ней шаблон «Схема модели базы данных» (рис. 2.3)	Рис. 2.3. Шаблон «Схема модели базы данных»
Прежде, чем приступить к созданию Логической модели, зайдите на вкладку «База данных» и в «Показать параметры» выставьте следующие настройки (рис. 2.4-2.6).	Рис. 2.4. Параметры документа (вкладка «Общие»)
Рис. 2.6. Параметры документа (вкладка «Отношение»)	Рис. 2.5. Параметры документа (вкладка «Таблица»)
Чтобы создать Сущность «Деталь», перетащите стереотип Сущность с панели инструментов на экран (рис. 2.7).	Рис. 2.7. Создание Сущности
Задайте имя новой Сущности в свойствах в нижней части экрана (рис. 2.8).	Рис. 2.8. Свойства Сущности («Определение»)
Затем на вкладке Столбцы создайте атрибуты Сущности, отметьте уникальный идентификатор (первичный ключ) галочкой в столбце PK и нажмите кнопку «ОК» (рис. 2.9).	Рис. 2.9. Свойства Сущности («Столбцы»)
Аналогично создайте вторую сущность, например «Материал». Чтобы создать связь между ними, перетащите стереотип «Отношение» точкой на изображение класса «Деталь», т.к. из каждого материала изготавливается ноль, одна или несколько деталей. Затем второй конец связи перетащите на изображение класса «Материал» (рис. 2.10). Внешний ключ «Код материала (FK)» автоматически появится в составе атрибутов сущности «Деталь». Незакрашенный ромб со стороны Материала означает, что материал может быть не указан. Чтобы убрать ромб, откройте свойства сущности «Деталь» и поставьте этому атрибуту галочку в столбце «Обязательное».	Рис. 2.10. Свойства отношения («Определение»)

Задание: постройте логическую модель базы данных в соответствии с описанием предметной области из вашего варианта задания.

Введение

Задачей курса "Проектирование Баз Данных" является не изучение особенностей той или иной СУБД, а освоение технологий создания и работы с базами данных. Проектирование информационных систем всегда начинается с определения цели проекта.

Настоящий лабораторный практикум написан для студентов специальности «Вычислительная техника и программное обеспечение» с учетом комментариев и предложений студентов, а также использованием реальных примеров, созданных студентами.

Хорошая база данных не получается случайно, структура ее содержимого должна тщательно прорабатываться, поэтому в лабораторной работе №1 на базе MS Visio достаточно подробно рассмотрен пример анализа предметной области или ТЗ (технического задания) организации учебного процесса с использованием системы оценки освоения дисциплин для создания учебной базы данных. Также приводится подробное описание примера проектирования базы данных. На самом деле, проектирование базы данных — это важная часть работы с БД, даже хорошая СУБД будет плохо работать с неудачно спроектированной базой данных.

Вывод требуемой информации из базы данных формулируется в виде запросов. Универсальным языком запросов к MS SQL Server является язык структурированных запросов SQL (Structured Query Language). Следует отметить, что язык SQL имеет множество диалектов, порожденных различными разработчиками.

В качестве используемой СУБД в лабораторных работах применяется система управления базами данных MS SQL Server 2008, хотя в равной степени это могла быть любая из современных СУБД. В последней версии MS SQL Server 2008 используется диалект Transact SQL, который базируется на существующем на сегодняшний день стандарте SQL для реляционных баз данных, установленном ANSI - Американским национальным институтом стандартов SQL 2003 и очень близок к нему. В методических указаниях достаточно подробно рассмотрены вопросы создания скриптов самой базы данных на языке SQL, манипуляции данными от создания простых до конструирования сложных запросов по поиску информации в спроектированной базе данных на диалекте Transact SQL.

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

Лабораторная работа № 1. Реализация структуры базы данных в MS Visio

 

1 Цель работы:а) получить навыки проектирования БД; б) ознакомление с методами и средствами создания ER-модели реляционных баз данных в среде MS Visio.

 

Задание на лабораторную работу

Спроектируйте модель данных учебного процесса в MS Visio: создайте представления «Преподаватели», «Кафедры», «Группы», «Студенты», «Предметы», «Учебный_процесс», «Успеваемость» и связи между ними на основании ER-диаграммы (Рисунок 1.1).

3.1Концептуальное проектирование базы данных

 

Прежде чем реализовывать структуру базы данных в MS Visio, необходимо создать проект этой базы данных на контрольном примере.

Контрольный ( или тестовый ) пример представляет собой упрощенный вариант реальной задачи, просчитываемый вручную вплоть до получения конечного результата. В контрольном примере указываются требования к объему и составу данных используемой исходной информации и результатов решения, рассматриваются основные понятия проектирования, как части рабочей среды, системный анализ которой приведен ниже.

С помощью контрольного примера проверим постановку задач обработки данных и работоспособность отдельных программ и информационной системы в целом.

Очень часто проектированию данных не уделяют должного внимания. Правильно спроектированная БД облегчает управление данными и становится цен­ным поставщиком информации. Плохо спроектированная БД вероятнее всего станет накопителем избыточной информации, т. е. неоправданного дублирования данных. Избыточность, как правило, затрудняет выявление ошибок в данных.Доступность современного превосходного программного обеспечения баз данных дает возможность даже новичкам создавать базы данных и приложения баз данных. К сожалению, подход "разработка без проекта" становится причиной множества провалов. Как показывает практика, многие, если не все, ошибки в плохо спроектированных системах баз данных не могут устранить даже лучшие программисты и менеджеры. При этом даже превосходная система управления базой данных (СУБД), вероятнее всего, не поможет разрешить проблемы, порожденные или усиленные плохим проектированием. Можно провести аналогию со строительством: даже лучшие каменщики и плотники не смогут построить хорошее здание по плохому проекту [2]. Большинство проблем в системах управления базами данных чаще всего возникает из-за плохого проектирования. Поскольку хранилища данных (data warehouse) получают информацию от рабочих (операционных) баз данных, концепции, структура и процедуры хранилищ данных станут более обоснованными, если вы будете достаточно хорошо разбираться в структуре и реализации рабочих БД. Проектирование баз данных имеет чрезвычайно важное практическое значение, чем и объясняется то внимание, которое ему уделено в первой лабораторной этой книги.В принципе, в результате создания базы данных мы получим каким-то образом связанные между собой таблицы, которые обоснованы на анализе данных (data mining), который является важнейшим компонентом в новейших системах принятия решений. На этапе анализа концептуальных требований и информационных потребностей необходимо решить следующие задачи:· анализ требований пользователей к БД (концептуальных требований);· выявление имеющихся задач по обработке информации, которая должна быть представлена в БД (анализ приложений);· выявление перспективных задач (перспективных приложений);· документирование результатов анализа. Чтобы исследовать различные аспекты использования СУБД, мы с вами рассмотрим сложный пример, приближенный к действительности, – ведение электронной документации деканата учебного заведения (ВУЗа), содержащую информацию об учебном процессе обучения студентов в вузах. Каждый вуз решает данную задачу по-своему, чаще всего без использования баз данных. Наш пример не является реальным примером обучения студентов в АИЭС или другом вузе, однако очень близок к тем задачам, которые стоят в действительности перед деканатами АИЭС и других вузов.

Организация учебного процесса с использованием системы оценки освоения дисциплин характеризуется следующими особенностями: необходимо учитывать списки студентов групп; перечень изучаемых предметов; преподавательский состав кафедр, обеспечивающих учебный процесс; сведения о лекционных, практических и других видах занятий в каждой группе; результаты сдачи экзаменов по каждому из проведенных занятий. Учебная программа строится в соответствии с утвержденным графиком на каждую специальность до начала учебного процесса. Учебная программа включает предлагаемые на факультете обязательные и элективные курсы. Каждому студенту предлагается учебный план на основе рабочего, исходя из того, что в процессе обучения он должен набрать заданное количество кредитов.

Если в системе обрабатывается информация о студентах, сущностью может являться студент, если обрабатывается информация об экзамене, то сущность – экзамен и т.п. Каждая сущность обладает определенным набором свойств (рассматриваем только свойства, представляющие интерес для пользователей в рамках проводимого исследования), которые запоминаются в информационной системе.

Так, например, в качестве свойств сущности СТУДЕНТ можно указать фамилию, дату рождения, место рождения, в качестве свойств сущности ЭКЗАМЕН – предмет, дату проведения экзамена, экзаменаторов.

Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ЭКЗАМЕН составляет класс сущностей ЭКЗАМЕН.

Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс.

Экземпляром сущности будем называть конкретную сущность (сущность с конкретными значениями соответствующих свойств).

Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности:

Класс сущностей Экземпляр сущности

СТУДЕНТ

Фамилия Иванов

Дата рождения 21.05.87

Место рождения Нижний Новгород

 

Взаимоотношения сущностей выражаются связями (Relationships).

Различают классы связей и экземпляры связей. Классы связей – это взаимоотношения между классами сущностей, а экземпляры связи – взаимоотношения между экземплярами сущностей. Класс связей может затрагивать несколько классов сущностей.

Число классов сущностей, участвующих в связи, называется степенью связи n = 2, 3, … Так, например, класс сущностей СТУДЕНТ связан с классом сущностей ЭКЗАМЕН связью «сдает». Степень этой связи равна двум. В качестве примера связи степени три можно указать связь «родители» между тремя классами сущностей МАТЬ, ОТЕЦ, РЕБЕНОК. При n=2 связь называется бинарной.

Рассмотрим классификацию бинарных связей.

Числа, которые описывают типы бинарных связей (1:1, 1:M, M:N), обозначают максимальное количество сущностей на каждой стороне связи. Эти числа называются максимальными кардинальными числами, а соответствующая пара чисел называется максимальной кардинальностью.

В зависимости от того, сколько экземпляров сущности одного класса связаны со сколькими экземплярами сущности другого класса, различают следующие типы связей:

· связь 1:1. Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Примером является связь «соответствует» между классами сущностей ФАКУЛЬТЕТ и РАСПИСАНИЕ ЭКЗАМЕНОВ НА ФАКУЛЬТЕТЕ (каждому факультету соответствует свое расписание, эта тема сама по себе сложная и рассматриваться в данной книге не будет).

· связь 1:M. Единый экземпляр сущности одного класса связан со многими экземплярами сущности другого класса. Примером является связь «обучение» между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете обучается много студентов).

· связь M:N. Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь «сдают» между классами сущностей СТУДЕНТ и ЭКЗАМЕН (каждый абитуриент сдает несколько экзаменов, и каждый экзамен сдают много студентов).

Чаще всего концептуальная модель представляется в виде диаграммы сущностей – связей (entity – relationship) или ER-диаграммы.

Процесс построения ER-диаграммы называется ER-моделированием. При этом используются следующие классические обозначения.

Класс сущностей представляется в виде четырехугольника. В четырехугольнике записано уникальное имя класса сущности (прописными буквами) и имена атрибутов строчными буквами, например:

 

СТУДЕНТ

Фамилия

Год рождения

Место рождения

 

Связи между сущностями обозначаются стрелками, рядом со стрелками указывается имя связи, а также максимальная кардинальность связи (максимальное число сущностей, которые могут участвовать в связи). Чтобы показать, что сущность обязана участвовать в связи (каждый экземпляр должен быть связан с экземпляром другого класса), на линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал.

Отношения между группами, предметами и преподавателями с их мощностями представлены на следующей схеме (рисунок 1.1). Атрибуты объектов на схеме не указаны.

 

Рисунок 1.1 – Диаграмма учебного процесса

 

При описании сущностей обычно выделяют особые совокупности атрибутов – ключи и внешние ключи. Ключ уникально идентифицирует экземпляр сущности и, вместе с внешним ключом, используется для реализации связей. На диаграммах атрибуты, входящие в первичный ключ, подчеркиваются (обозначение РК).

Важность понятий ключа и внешнего ключа будет проиллюстрирована далее на примерах.

Приведенные выше обозначения не являются общеупотребительными. Часто производитель программ, позволяющих рисовать ER-диаграммы, использует свою систему обозначений. Например, при использовании программы MS Visio в качестве основной используется так называемая реляционная нотация. В данной системе обозначений связи обозначаются стрелками между сущностями и названия связей не пишутся. Название сущности выделяется цветом, поля, входящие в первичный ключ, отделяются чертой от остальных атрибутов. Обязательные атрибуты отображаются с помощью полужирного шрифта.

Кроме того, слева от атрибута указывается, входит ли данный атрибут в первичный ключ, а также является ли атрибут внешним ключом.

На практике использование различных способов записи ER-диаграмм не представляет особой сложности – беглое ознакомление с соответствующим разделом документации позволяет быстро освоить используемую систему обозначений.

При разработке концептуальной модели, прежде всего, следует определить сущности. С этой целью нужно сделать следующее:

· необходимо понять, какая информация должна храниться и обрабатываться, и можно ли это определить как сущность;

· присвоить этой сущности имя;

· выявить атрибуты сущности и присвоить им имя.

· выявив сущности, необходимо определить, какие связи имеются между ними.

· при определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам обработки данных) необходимо учитывать следующее:

· то, как экземпляр одной сущности связан с экземпляром другой сущности;

· то, как должны быть установлены связи, чтобы была возможность ответа на все запросы пользователей (исходя из их информационных потребностей).

 

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

Источники информации:

Администраторы БД – на основе официальных документов и отчетностей формируют структуру БД, изменяя и дополняя ее.

Преподаватели – предоставляют информацию.

Студенты – предоставляют информацию.

Сотрудники, не занимающиеся преподавательской деятельностью – предоставляют информацию.

В процессе анализа предметной области ОБУЧЕНИЕ СТУДЕНТОВ (не забывая, что это учебный пример и весь процесс глубоко не рассматривается) выделяются отдельные сущности.

Поскольку вещи одного типа хранятся в отдельных объектных множествах, можем выделить следующие сущности: СПЕЦИАЛЬНОСТИ, ГРУППЫ, СТУДЕНТЫ, КАФЕДРЫ, ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ, УЧЕБНЫЙ ПРОЦЕСС, УСПЕВАЕМОСТЬ.

В контрольном примере рассматривается только часть бизнес-правил учебного процесса.

В соответствии с предметной областью система строится с учетом следующих особенностей. Например:

· студент не может учиться на двух специальностях и в двух группах одновременно;

· не может быть двух студентов с одинаковыми номерами зачетной книжки;

· на кафедре работает много преподавателей;

· не может быть двух кабинетов с одинаковыми номерами;

· у кафедры не может быть несколько заведующих кафедрой;

· у группы может быть только один староста;

· по результатам промежуточной аттестации студенту выставляется дифференцированная оценка в принятой в вузе системе баллов, характеризующая качество освоения студентом знаний, умений и навыков по данной дисциплине;

· преподаватель может вести один и тот же предмет в нескольких группах или несколько разных предметов в одной группе;

Яндекс.Директ

Обучениелабораторномуделу!Дистанционная переподготовка и повышение квалификации. Начните обучаться сейчас!

Курсы дляучителей информатики!Дистанционные курсы дляучителей информатики. ФИПКиП! Диплом! Идет набор!

· студенты сдают экзамены по предметам, которые они изучали;

· у группы может быть только один куратор;

· преподаватель может занимать только одну должность;

· преподаватель может иметь только одну ученую степень;

· не может быть двух одинаковых специальностей;

· не может быть двух одинаковых ученых степеней;

· не может быть двух одинаковых должностей;

· группа занимается только по одному учебному плану.

 

Может быть сформулировано множество вопросов к базе данных, например: к какой группе относится студент, на каких кафедрах работают преподаватели, какие предметы, в каких группах они ведут, какую оценку получили студенты по определенным видам занятий по определенному предмету и т.д. Чтобы ответить на широкий круг возможных вопросов к базе данных, следует рассмотреть отношения между объектными множествами, необходимо присвоить связям имена и определить тип связей.

Между объектами ГРУППЫ и СТУДЕНТЫ существует отношение «один-ко-многим», поскольку одна группа включает много студентов, а один студент входит только в одну группу. Аналогично устанавливается связь между объектами КАФЕДРЫ и ПРЕПОДАВАТЕЛИ, которые также находятся в отношениях «один-ко-многим» (на одной кафедре работает много преподавателей, но каждый преподаватель работает на определенной кафедре). По каждому предмету проводится множество видов занятий в различных группах разными преподавателями. Это определяет отношения «многие-ко-многим» между множествами ГРУППЫ и ПРЕДМЕТЫ, ГРУППЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ВИДЫ_ЗАНЯТИЙ.

Яндекс.Директ

Повышение квалификациипедагогов!Дистанционно. ФГОС. Скидки! Быстро! Лицензия. 2 документа: удостоверение и сертификат!СкидкиДокументы об окончанииОтзывыКонтактыpedcampus.ruАдрес и телефон