Лабораторная работа № 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Адрес и телефон

 

Пример построения подробной диаграммы «сущность – связь» для предметной области «Учебный процесс»

 

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

· Специальности (SPECIALITY). Атрибуты – номер, название специальности. Эта сущность необходима, т.к. студент поступает в ВУЗ на специальность, а потом распределяется по группам.

· Группы (GRUP). Атрибуты этой таблицы – номер, название, количество студентов, курс. Эта сущность отводится для хранения сведений о группах. Так как названия групп формируются в зависимости от факультета, кафедры, года поступления и будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут Grup_ID – это ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования.

· Студенты (STUDENTS). Эта сущность отводится для хранения сведений о студентах. Атрибуты – номер, фамилия, имя, отчество, дата рождения, адрес, номер группы, студент-староста. Stud_ID (идентификационный номер студента – обычно номер зачетной книжки) выбран в качестве первичного ключа (PK). Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, поскольку может появиться несколько однофамильцев. Это же правило относится к сочетанию фамилия-имя (отчества может не быть вообще). А учитывая, что идентификаторы студентов будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера.

· Кафедры (CHAIR). Атрибуты - номер, название, телефон и адрес. Эта сущность вводится для хранения сведений о кафедрах вуза. Chair_ID – это целочисленное ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования автоматически.

· Преподаватели (TEACHER). Атрибуты – номер, фамилия, имя, отчество, должность, ученая степень и принадлежность к кафедре. Эта сущность отводится для хранения сведений о преподавателях. Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, а учитывая, что идентификаторы преподавателей будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут Teach_ID – это ключевое поле, которое и будет идентификатором данной сущности.

· Предметы (SUBJECT). Атрибуты – номер, название, общее количество часов за семестр, лекционные часы, часы практикумов, лабораторные часы. Эта сущность отводится для хранения сведений о предметах. Атрибут Subj_ID – это ключевое поле, которое и будет идентификатором данной сущности. Атрибут Subj_NAME является текстовым типом данных для отображения названия предмета.

 

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

Бизнес-правила это краткое и точное повествовательное описание политики, процедур и норм в условиях предприятия. Если бизнес-правила заданы корректно, то в них определяются и сущности, и атрибуты, и связи, и связности, и мощность, и ограничения. Некоторые бизнес-правила реализуются при помощи триггеров и процедур. Бизнес-правила должны быть не только эффективными, но понятными, и к тому же они описывают на простом языке основные и точные характеристики данных с точки зрения компании.

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

Бизнес-правило 1

Каждый студент поступает на одну специальность. На основе первого бизнес-правила мы получаем сегмент ER-модели, представленный на рис.1.2.

Рисунок 1.2 – ER–диаграмма бизнес-правила 1

Бизнес-правило 2

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

На основе Бизнес-правила 2 мы получаем следующий сегмент ER-модели.

Рисунок 1.3 – ER–диаграмма бизнес-правила2

Бизнес-правило 3

Преподаватель не может работать на нескольких кафедрах, преподаватель числится только на одной кафедре в данный момент времени. Тем временем на кафедре работают много преподавателей.

На основе Бизнес-правила 3 мы получаем следующий сегмент ER-Модели

Рисунок 1.4 – ER–диаграмма бизнес-правила 3

Бизнес-правило 4

Каждая группа (соответственно и студент в ней) изучает конкретное множество предметов, которые ведут преподаватели. Преподаватель может вести один и тот же предмет в нескольких группах и несколько разных предметов изучаются одной группой. Связь «многие-ко-многим» реализуем через ассоциативную таблицу, так как на сегодня ни одна СУБД такую связь не реализует.Сотрудники кафедры ведут занятия у нескольких групп, для этого таблицу «Учебный процесс» связываем с таблицей «Преподаватели» связью 1:М.

То есть появляется еще одна таблица «Учебный процесс».

· Учебный процесс (STUDY). Сущность включает атрибуты - номер группы, номер предмета, номер преподавателя, форма обучения, количество часов. Атрибут Grup_ID отображает в формате integer группу, участвующую в учебном процессе. Атрибут Subj_ID отображает в формате integer предмет, относящийся к данной группе. Атрибут Teach_ID – это целочисленное поле, хранящее информацию о преподавателе, ведущем данный предмет. Атрибут Kredit_count – символьное поле, характеризующее форму обучения. Атрибут Total_Hours является целочисленным типом данных для отображения общего количества часов. Атрибут Lection_Hours является целочисленным типом данных для отображения количества лекционных часов. Атрибут Practice_Hours является целочисленным типом данных для отображения количества часов практикума. Атрибут Labor_Hours является целочисленным типом данных для отображения количества лабораторных часов.

На основе Бизнес-правила 4 мы получаем следующий сегмент ER-Модели

 

Рисунок 1.5 – ER–диаграмма бизнес-правила 4

Бизнес-правило 5

Студенты сдают экзамены по предметам, которые они изучали. Например, если студент входит в группу 1, а этой группой в учебном процессе изучался предмет 2, то студент должен будет сдать данный предмет. Связь «многие-ко-многим» реализуется через ассоциативную таблицу «Успеваемость»:

Успеваемость (PROGRESS). Сущность включает атрибуты - код студента, код группы, код предмета, код преподавателя, дату сдачи, итоговую оценку. Данная сущность хранит данные об успеваемости каждого студента.

На основе Бизнес-правила 5 мы получаем следующий сегмент ER-Модели

 

Рисунок 1.6 –ER–диаграмма бизнес-правила 5

 

База данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей (рис. 1.6).

 

Рисунок 1.6 – Уточненная ER–диаграмма концептуальной модели учебного процесса

 

3.7 Преобразование концептуальной модели в реляционную модель

 

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

Преобразование объектных множеств и атрибутов. Объектное множество с атрибутами может быть преобразовано в реляционную таблицу с именем объектного множества в качестве имени таблицы и атрибутами объектного множества в качестве атрибутов таблицы. Если некоторый набор этих атрибутов может быть использован в качестве ключа таблицы, то он выбирается ключом таблицы. В противном случае в таблицу добавляется атрибут, значения которого будут однозначно определять объекты-элементы исходного объектного множества, и который, таким образом, может служить ключом таблицы. Преобразуем объектные множества ГРУППЫ, КАФЕДРЫ, ПРЕДМЕТЫ в реляционные таблицы с соответствующими названиями.

Каждое реляционное отношение соответствует одной сущности, и в него вносятся все атрибуты сущности. Для каждого отношения необходимо определить окончательно первичный ключ и внешние ключи (если они имеются). Отношения приведены в таблицах 2-8.

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

N – числовой (numeric);

C – символьный (char);

D – дата (различная стандартная длина для каждой СУБД, поэтому она не указывается).

В полях примечание первичные и внешние ключи также подразумеваются обязательными полями (NOT NULL).

Программа MS Visio предназначена для создания различного вида чертежей: от схем сетей до календарей, от планов офиса до блок-схем, а также структур баз данных.

Существует много типов документов Visio, но для создания практически всех документов можно воспользоваться тремя основными действиями:

1. Выбор и открытие шаблона.

2. Перетаскивание и соединение фигур.

3. Добавление текста (данных) в фигуры.

Выбор и открытие шаблона:

1. Откройте программу Visio 2007.

2. В списке Категории шаблонов выберите элемент Программное обеспечение и базы данных.

3. В диалоговом окне ПО и БД в области Готовые шаблоны дважды щелкните элемент Схема модели базы данных.

После открытия шаблона будут открыты необходимые коллекции фигур, которые называются наборами элементов. Наборы элементов, которые открываются с шаблоном Схема модели базы данных, называются Отношение сущности.

 

Рисунок 1.7 – Наборы элементов для работы с моделью базы данных в Visio

Перетащите первую фигуру (сущность, (Entity)) из набора элементов отношение сущности на страницу документа и отпустите кнопку мыши.

Рисунок 1.8 – Создание сущности (таблицы)

Фигуры Visio — это гораздо больше, чем просто изображения или символы.

Задайте свойства базы данных. Для этого щелкните по созданной фигуре (Таблица 1). Соответствующее окно (свойства базы данных, Рисунок 1.9) будет открыто в нижней части экрана.

Рисунок 1.9 – Свойства базы данных

В категории Определение введите физическое имя сущности (Студенты). Затем перейдите в категорию Колонки и введите данные соответствующие этой сущности.

Рисунок 1.10 – Добавление атрибутов таблицы

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

Рисунок 1.11 – Результат создания таблицы “Студенты”

Подобным образом необходимо создать все сущности базы данных “учебного процесса”, описанные в пункте 1.7.

После того, как создание всех сущностей завершено, необходимо создать отношения между таблицами. Для этого необходимо перетащить фигуру Отношение из набора элементов Отношение сущности (Рисунок 1.12)

Рисунок 1.12 – Создание отношения

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

 

Для реализации часть спроектированной модели данных учебного процесса в среде СУБД MS SQL Server 2008 создайте таблицы «Преподаватели», «Кафедры», «Группы» и «Студенты», «Предметы», «Специальности», «Учебный план», «Успеваемость». В лабораторной работе для объектов рассматриваемой базы данных применяются названия на английском языке. Это связано с требованиями используемого программного обеспечения. Поэтому в приведенных ниже примерах база данных называется “Education”. Для создания любого объекта SQL Server существует несколько способов, базирующихся на выполнении определенной команды.

Размещение пользовательских баз может меняться в зависимости от версии SQL и размещения Program Files. Выяснить место расположения пользовательских баз можно из основного окна программы, выбрав из контекстного меню Свойства (Properties) любой базы в списке Databases. Также в окне свойств на вкладке TransactionLog просмотрите место расположения журнала транзакций. Команды резервного копирования и восстановления базы данных тоже выбираются в контекстном меню: строка Все задачи (All Tasks), команды Backup Databases и Restore Databases.

 

Создание базы данных

 

Физически база данных располагается в одном или нескольких файлах операционной системы. В одном файле операционной системы не может содержаться несколько баз данных. В этом файле хранятся такие объекты, как таблицы и индексы. Журнал транзакций – это рабочие области, которые SQL Server применяет для записи информации до и после выполнения транзакции. Эта информация может использоваться для отмены выполненной транзакции или для восстановления базы данных, если возникнет такая необходимость. В MS SQL Server 2008 журналы транзакций хранятся в отдельном файле, а не вместе с таблицами, как было в предыдущих версиях. Для создания базы данных с помощью Transact-SQL используется команда CREATE DATABASE. Полный синтаксис команды приводить не будем, т.к. он занимает несколько страниц.

 

CREATE DATABASE lab_Study

ON PRIMARY

(NAME = education_data, FILENAME='C:\Data\education_data.mdf', size = 4,

maxsize =25, filegrowth = 1 mb)

LOG ON

(NAME = education_log, FILENAME='C:\Data\education_log.ldf', size = 4, maxsize = 20, filegrowth =1 mb);

 

Внимание: Размещение базы и журнала транзакций - 'С:\…’ - может меняться в зависимости от версии SQL и размещения Program Files.

Здесь:

- education имя создаваемой базы данных.

- ON определяет список файлов на диске, в которых будет храниться информация базы данных.

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

 

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

Интернет вчастный домРОСТЕЛЕКОМ Интернет 30-200 Мбит. Цифровое ТВ. Проверьте адрес на сайте РОСТЕЛЕКОМ!

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

 

- LOG ON определяет список файлов на диске, в которых будет храниться журнал транзакций. Если этот параметр не определен, то размер журнала транзакций будет составлять 25% от общего размера файлов данных.

- education_data определяет логическое имя, которое SQL Server будет использовать для обращения к файлу.

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

Для создания таблиц и манипулирования ими внутри базы данных необходимо ввести понятие схемы. Схема представляет собой группу связанных между собой объектов базы данных (например, таблиц и индексов). Обычно схема является собственностью пользователя или приложения. В одной базе данных может храниться несколько схем, принадлежащих разным пользователям и приложениям. Можно представлять себе схему как логически сгруппированные таблицы или логическую базу данных, что постоянно используется при проектировании баз данных больших компаний и OLTP - БД. Схемы полезны тем, что группируют таблицы по владельцам и обеспечивают первый уровень защиты, разрешая пользователю просматривать таблицы, принадлежащие только ему. Если используемая вами РСУБД соответствует стандартам ANSI, то схема БД создается командой:

 

CREATE SCHEMA AUTHORIZATION <creator>;

 

Поэтому если создателем является Ruslan, то команда будет выглядеть так:

CREATE SCHEMA AUTHORIZATION Ruslan;

 

Схемы и пользователи баз данных разделены – пользователи владеют схемами.

Для обращения к объектам, обычно используется двухсоставной идентификатор database_name.object_name ( Education.Students ).

Если используется схема, то используется трехсоставной идентификатор database_name.shema_name.object_name. В пределах базы данных это имя можно сократить до схема.объект. Т.е., если в базе существуют модули Отдел кадров, Бухгалтерия, Деканат, то таблицы могут быть разнесены по модулям (схемам).

Перед созданием таблиц необходимо определить текущую базу данных с помощью следующей команды:

USE lab_Study;

 

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

Создадим две схемы для обучения студентов StudySchema (таблицы Группы, Студенты, Предметы, Учебный план и Успеваемость) и данных деканата DekanatSchema (таблицы Кафедры и Преподаватели):

 

CREATE SCHEMA StudySchema

GO

CREATE SCHEMA DekanatSchema

GO

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

Создание таблиц

 

 

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

Таблицу можно создать с помощью оператора CREATE TABLE языка SQL.

Синтаксис:

({ < column_definition > | < table_constraint > } [,...n ]

)

< column_definition >::=

{ column_name data_type }

[ { DEFAULT constant_expression

| [ IDENTITY [ (seed, increment) ]

]

} ]

[ ROWGUIDCOL ]

[ < column_constraint > [...n ] ]

< column_constraint >::=

[ CONSTRAINT constraint_name ]

{ [ NULL | NOT NULL ]

| [ PRIMARY KEY | UNIQUE ]

| REFERENCES ref_table [ (ref_column) ]

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]

}

< table_constraint >::=

[ CONSTRAINT constraint_name ]

{ [ { PRIMARY KEY | UNIQUE }

{ (column [,...n ]) }

]

| FOREIGN KEY

(column [,...n ])

REFERENCES ref_table [ (ref_column [,...n ]) ]

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]

}

Замечания

· Аргументы и ограничения рассматриваются в справке оператора CREATE TABLE;

· Определения столбца: при создании таблицы необходимо указать, по крайней мере, одно определение столбца.