бд. метод указ Проектирование БД. Методическое указания для выполнение лабораторных работ по дисциплине
 Скачать 0.74 Mb.
|
|
Методическое указания для выполнение лабораторных работ по дисциплине PHDBSS 3207– «Проектирование хранилищ данных на базе современных СУБД» 6B06101 - «Информационные системы» Алматы, 2021г Введение В настоящих методических указаниях решается задача анализа предметной области организации учебного процесса с использованием системы оценки освоения дисциплин для создания базы данных. Хорошая база данных не получается случайно, структура ее содержимого должна тщательно прорабатываться, поэтому данный вопрос достаточно подробно рассмотрен в лабораторной работе №1 на базе MS Visio. Создание базы данных На самом деле, проектирование базы данных — это важная часть работы с БД Даже хорошая СУБД будет плохо работать с неудачно спроектированной базой данных. Время, по сути, сделало язык SQL стандартом de-facto в области работы с базами данных, а международные стандарты языка SQL (стандарты SQL/89, SQL2, SQL/3) позволяют в значительной степени унифицировать средства доступа к данным вне зависимости от используемой СУБД. В качестве используемой СУБД в лабораторных работах применяется система управления базами данных MS SQL Server 2008, хотя в равной степени это могла быть любая из современных СУБД. Требование нужной информации из базы данных формулируется в виде запросов. Универсальным языком запросов к SQL Server является язык структурированных запросов SQL (Structured Query Language). Следует отметить, что язык SQL имеет множество диалектов, порожденных различными разработчиками. В последней версии MS SQL Server 2008 используется диалект Transact SQL, который базируется на SQL 2003 и очень близок к нему (SQL 2003- существующий на сегодня стандарт SQL для реляционных баз данных, установленный ANSI - Американским национальным институтом стандартов). В методических указаниях достаточно подробно рассмотрены вопросы создания скриптов самой базы данных на языке SQL, манипуляции данными от создания простых до конструирования сложных запросов по поиску информации в спроектированной базе данных на диалекте Transact SQL. На сегодняшний день нет идеальной системы управления базами данных, имеющей как развитый интерфейс, так и оптимизированную структуру. СУБД MS SQL Server 2008 не имеет интерфейса с пользователем в обычном понимании. Однако эта система является высокоэффективным хранилищем с развитыми средствами работы с данными и возможностями создавать приложения для работы с базой данных непрофессиональным пользователям. В методических указаниях приведен пример настройки доступа к источнику данных СУБД MS SQL Server 2008 среды Delphi для создания клиентского приложения. Лабораторная работа № 1. Реализация структуры базы данных в MS Visio 1 Цель работы: а) получить навыки проектирования БД; б) ознакомление с методами и средствами создания ER-модели реляционных баз данных в среде MS Visio. 2 Задание на лабораторную работу Спроектируйте модель данных учебного процесса в MS Visio: создайте представления «Преподаватели», «Кафедры», «Группы», «Студенты», «Предметы», «Учебный_процесс», «Успеваемость» и связи между ними на основании ER-диаграммы (Рисунок 1.6). 3 Методические указания к выполнению лабораторной работы 3.1 Концептуальное проектирование базы данных Прежде чем реализовывать структуру базы данных в MS Visio, необходимо создать проект этой базы данных на контрольном примере. Контрольный ( или тестовый ) пример представляет собой упрощенный вариант реальной задачи, просчитываемый вручную вплоть до получения конечного результата. В контрольном примере указываются требования к объему и составу данных используемой исходной информации и результатов решения. С помощью контрольного примера проверяют постановку задач обработки данных и работоспособность отдельных программ и информационной системы в целом. Правильно спроектированная БД облегчает управление данными и становится ценным поставщиком информации. Плохо спроектированная БД вероятнее всего станет накопителем избыточной информации, т. е. неоправданного дублирования данных. Избыточность, как правило, затрудняет выявление ошибок в данных. На этапе анализа концептуальных требований и информационных потребностей необходимо решить следующие задачи: анализ требований пользователей к БД (концептуальных требований); выявление имеющихся задач по обработке информации, которая должна быть представлена в БД (анализ приложений); выявление перспективных задач (перспективных приложений); документирование результатов анализа. Чтобы исследовать различные аспекты использования СУБД, мы рассмотрим сложный пример, приближенный к действительности, – ведение электронной документации учебного заведения (вуза), содержащую информацию об учебном процессе обучения студентов в вузах. Каждый вуз решает данную задачу по-своему, чаще всего без использования баз данных. Наш пример не является реальным примером обучения студентов в АИЭС или другом вузе, однако очень близок к тем задачам, которые стоят в действительности перед деканатами АИЭС и других вузов. Организация учебного процесса с использованием системы оценки освоения дисциплин характеризуется следующими особенностями: необходимо учитывать списки студентов групп; перечень изучаемых предметов; преподавательский состав кафедр, обеспечивающих учебный процесс; сведения о лекционных, практических и других видах занятий в каждой группе; результаты сдачи экзаменов по каждому из проведенных занятий. Учебная программа строится в соответствии с утвержденным графиком на каждую специальность до начала учебного процесса. Учебная программа включает предлагаемые на факультете обязательные и элективные курсы. Каждому студенту предлагается учебный план на основе рабочего, исходя из того, что в процессе обучения он должен набрать заданное количество кредитов. 3.2 Описание предметной области Если в системе обрабатывается информация о студентах сущностью может являться студент, если обрабатывается информация об экзамене, то сущность – экзамен и т.п. Каждая сущность обладает определенным набором свойств (рассматриваем только свойства, представляющие интерес для пользователей в рамках проводимого исследования), которые запоминаются в информационной системе. Так, например, в качестве свойств сущности СТУДЕНТ можно указать фамилию, дату рождения, место рождения, в качестве свойств сущности ЭКЗАМЕН – предмет, дату проведения экзамена, экзаменаторов. Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ЭКЗАМЕН составляет класс сущностей ЭКЗАМЕН. Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс. Экземпляром сущности будем называть конкретную сущность (сущность с конкретными значениями соответствующих свойств). Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности: Класс сущностей Экземпляр сущности СТУДЕНТ Фамилия Иванов Дата рождения 21.05.87 Место рождения Нижний Новгород Взаимоотношения сущностей выражаются связями (Relationships). Различают классы связей и экземпляры связей. Классы связей – это взаимоотношения между классами сущностей, а экземпляры связи – взаимоотношения между экземплярами сущностей. Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи n = 2, 3, … Так, например, класс сущностей СТУДЕНТ связан с классом сущностей ЭКЗАМЕН связью «сдает». Степень этой связи равна двум. В качестве примера связи степени три можно указать связь «родители» между тремя классами сущностей МАТЬ, ОТЕЦ, РЕБЕНОК. При n=2 связь называется бинарной. Рассмотрим классификацию бинарных связей. Числа, описывающие типы бинарных связей (1:1, 1:M, M:N), обозначают максимальное количество сущностей на каждой стороне связи. Эти числа называются максимальными кардинальными числами, а соответствующая пара чисел называется максимальной кардинальностью. В зависимости от того, сколько экземпляров сущности одного класса связаны со сколькими экземплярами сущности другого класса, различают следующие типы связей: связь 1:1. Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Примером является связь «соответствует» между классами сущностей ФАКУЛЬТЕТ и РАСПИСАНИЕ ЭКЗАМЕНОВ НА ФАКУЛЬТЕТЕ (каждому факультету соответствует свое расписание). связь 1:M. Единый экземпляр сущности одного класса связан со многими экземплярами сущности другого класса. Примером является связь «обучение» между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете обучается много студентов). связь M:N. Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь «сдают» между классами сущностей СТУДЕНТ и ЭКЗАМЕН (каждый абитуриент сдает несколько экзаменов, и каждый экзамен сдают много студентов). 3.3 Описание информационного представления предметной области В качестве основного понятия для описания предметной области, как уже отмечалось, используется понятие сущности (объекта), характеризуемой набором определенных свойств. Для информационного описания сущности вводится понятие атрибута. Атрибут – поименованное свойство (характеристика) сущности. Атрибут представляет собой информационное отображение свойства сущности и принимает конкретное значение из множества допустимых значений. Так, например, для сущности СТУДЕНТ атрибут «фамилия» у конкретного экземпляра сущности принимает конкретное значение «Иванов». Другим основным понятием для описания предметной области является понятие связи. Для представления связей между экземплярами сущностей могут использоваться атрибуты. В этом случае связь устанавливается путем включения в совокупность атрибутов сущности атрибута, однозначно идентифицирующего экземпляр сущности, находящийся в отношении с исходным экземпляром сущности. Так, если мы рассмотрим класс сущностей ПРЕДМЕТ, представленный одной совокупностью атрибутов (название, номер), и класс сущностей УСПЕВАЕМОСТЬ , представленный другой совокупностью атрибутов (код студента, название предмета, дата экзамена, группа студента, оценка). Для представления связи «экзамены» (тип связи 1:1) в совокупность атрибутов УСПЕВАЕМОСТЬ можно включить атрибут «название предмета». 3.4 Построение ER-диаграмм Чаще всего концептуальная модель представляется в виде диаграммы сущностей – связей (entity – relationship) или ER-диаграммы. Процесс построения ER-диаграммы называется ER-моделированием. При этом используются следующие классические обозначения. Класс сущностей представляется в виде четырехугольника. В четырехугольнике записано уникальное имя класса сущности (прописными буквами) и имена атрибутов строчными буквами. СТУДЕНТ Фамилия Год рождения Место рождения Связи между сущностями обозначаются стрелками, рядом со стрелками указывается имя связи, а также максимальная кардинальность связи (максимальное число сущностей, которые могут участвовать в связи). Чтобы показать, что сущность обязана участвовать в связи (каждый экземпляр должен быть связан с экземпляром другого класса), на линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал. Отношения между группами, предметами и преподавателями с их мощностями представлены на следующей схеме (рисунок 1.1). Атрибуты объектов на схеме не указаны.  Рисунок 1.1 – Диаграмма учебного процесса При описании сущностей выделяют особые совокупности атрибутов – ключи и внешние ключи. Ключ уникально идентифицирует экземпляр сущности и, вместе с внешним ключом, используется для реализации связей. На диаграммах атрибуты, входящие в первичный ключ, подчеркиваются (обозначение РК). Важность понятий ключа и внешнего ключа будет проиллюстрирована далее на примерах. Приведенные выше обозначения не являются общеупотребительными. Часто производитель программ, позволяющих рисовать ER-диаграммы, использует свою систему обозначений. Например, при использовании программы MS Visio в качестве основной используется так называемая реляционная нотация. В данной системе обозначений связи обозначаются стрелками между сущностями и названия связей не пишутся. Название сущности выделяется цветом, поля, входящие в первичный ключ, отделяются чертой от остальных атрибутов. Обязательные атрибуты отображаются с помощью полужирного шрифта. Кроме того, слева от атрибута указывается, входит ли данный атрибут в первичный ключ, а также является ли атрибут внешним ключом. На практике использование различных способов записи ER-диаграмм не представляет особой сложности – беглое ознакомление с соответствующим разделом документации позволяет быстро освоить используемую систему обозначений. 3.5 Выявление и моделирование сущностей и связей При разработке концептуальной модели, прежде всего, следует определить сущности. С этой целью нужно сделать следующее: необходимо понять, какая информация должна храниться и обрабатываться, и можно ли это определить как сущность; присвоить этой сущности имя; выявить атрибуты сущности и присвоить им имя. выявив сущности, необходимо определить, какие связи имеются между ними. при определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам обработки данных) необходимо учитывать следующее: то, как экземпляр одной сущности связан с экземпляром другой сущности; то, как должны быть установлены связи, чтобы была возможность ответа на все запросы пользователей (исходя из их информационных потребностей). Поскольку вещи одного типа хранятся в отдельных объектных множествах, можем выделить следующие сущности: ГРУППЫ, СТУДЕНТЫ, КАФЕДРЫ, ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ, УЧЕБНЫЙ ПРОЦЕСС, УСПЕВАЕМОСТЬ. При создании концептуальной модели необходимо учитывать ряд условий – ограничений (в современной терминологии бизнес-правила): В контрольном примере рассматривается только часть бизнес-правил учебного процесса. Например: по результатам промежуточной аттестации студенту выставляется дифференцированная оценка в принятой в вузе системе баллов, характеризующая качество освоения студентом знаний, умений и навыков по данной дисциплине. студент не может учиться в двух группах одновременно. не может быть двух студентов с одинаковыми номерами зачетной книжки. преподаватель не может работать на нескольких кафедрах на кафедре работает много преподавателей преподаватель может вести один и тот же предмет в нескольких группах или несколько разных предметов в одной группе студенты сдают экзамены по предметам, которые они изучали. Может быть сформулировано множество вопросов к базе данных, например: к какой группе относится студент, на каких кафедрах работают преподаватели, какие предметы, в каких группах они ведут, какую оценку получили студенты по определенным видам занятий по определенному предмету и т.д. Чтобы ответить на широкий круг возможных вопросов к базе данных, следует рассмотреть отношения между объектными множествами, необходимо присвоить связям имена и определить тип связей. Между объектами ГРУППЫ и СТУДЕНТЫ существует отношение «один-ко-многим», поскольку одна группа включает много студентов, а один студент входит только в одну группу. Аналогично устанавливается связь между объектами КАФЕДРЫ и ПРЕПОДАВАТЕЛИ, которые также находятся в отношениях «один-ко-многим» (на одной кафедре работает много преподавателей, но каждый преподаватель работает на определенной кафедре). По каждому предмету проводится множество видов занятий в различных группах разными преподавателями. Это определяет отношения «многие-ко-многим» между множествами ГРУППЫ и ПРЕДМЕТЫ, ГРУППЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ВИДЫ_ЗАНЯТИЙ. 3.6 Пример построения подробной диаграммы «сущность – связь» для предметной области «Учебный процесс» Исходя из выше изложенного, можно выделить следующие базовые сущности нашей предметной области: Группы. Атрибуты этой таблицы – номер, название, количество студентов, курс. Эта сущность отводится для хранения сведений о группах. Так как названия групп формируются в зависимости от факультета, кафедры, года поступления и будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Grup_ID" – это ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования. Студенты. Атрибуты – номер, фамилия, имя, отчество, дата рождения, адрес, номер группы, студент-староста. Эта сущность отводится для хранения сведений о студентах. Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, а учитывая, что идентификаторы студентов будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Кафедры. Атрибуты - номер, название, телефон и адрес. Эта сущность вводится для хранения сведений о кафедрах вуза. "Chair_ID" – это целочисленное ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования автоматически. Преподаватели. Атрибуты – номер, фамилия, имя, отчество, должность, ученая степень и принадлежность к кафедре. Эта сущность отводится для хранения сведений о преподавателях. Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, а учитывая, что идентификаторы преподавателей будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Teach_ID" – это ключевое поле, которое и будет идентификатором данной сущности. Предметы. Атрибуты – номер, название, общее количество часов за семестр, лекционные часы, часы практикумов, лабораторные часы. Эта сущность отводится для хранения сведений о предметах. Атрибут "Subj_ID" – это ключевое поле, которое и будет идентификатором данной сущности. Атрибут «Subj_NAME» является текстовым типом данных для отображения названия предмета. Атрибут «Total_Hours» является целочисленным типом данных для отображения общего количества часов. Атрибут «Lection_Hours» является целочисленным типом данных для отображения количества лекционных часов. Атрибут «Practice_Hours» является целочисленным типом данных для отображения количества часов практикума. Атрибут «Labor_Hours» является целочисленным типом данных для отображения количества лабораторных часов. Связи между сущностями базируются на бизнес-правилах, построенных на основе подробного описания операций. В процессе ER-моделирования системы учебного процесса был получен следующий набор бизнес-правил для сущностей и связей. |