Имя_столбца тип constraint имя_ограничения ограничение

УДК 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 частей, любая из которых соответствует конкретной лабораторной работе.

Для исполнения лабораторных работ нужно следующее ПО:

1. Построение диаграмм IDEF1X – к примеру Borland Together Designer, ERWin4.0.;

2. 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” в раскрывающемся перечне на панели инструментов.

Вопросы к допуску

1. Дайте определение процессу проектирования базы данных;

2. Какова главная цель логического проектирования?

3. Перечислите и коротко охарактеризуйте этапы логического проектирования;

4. Что именуется сущностью?

5. В чем отличие между сильными и не сильный сущностями?

6. Дайте определение атрибуту сущности;

7. Что именуют связью? Какие конкретно характеристики может иметь сообщение?

8. Как изображают сущности, связи и атрибуты в хороших диаграммах Чена?

Контрольные вопросы

1. Какие конкретно виды моделей поддерживает ERWin?

2. Какие конкретно объекты разрешает создавать ERWin в логической модели?

3. Какими методами возможно создавать сущности в ERWin?

4. На какие конкретно части делится сущность в ERWin?

5. Какими методами возможно добавить атрибут к сущности?

6. Как указать атрибуты, входящие в состав первичного ключа?

7. Перечислите применяемые в ERWin группировки атрибутов;

8. Какого именно рода атрибуты входят в состав группы AKn?

9. Для чего применяют группу IEn?

10. Дайте определение идентифицирующей связи. В каких случаях применяют данный вид связи?

11. Дайте определение неидентифицирующей связи. В каких случаях применяют данный вид связи?

12. В каких случаях применяют связи «многие ко многим»?

13. Что такое «сообщение категоризации»? Как создавать подобные связи?

14. Какие конкретно виды кардинальностей поддерживает ERWin?

Лабораторная работа №2:
«Физическое проектирование: построение схемы данных»

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

  • Произвести переименование атрибутов и отношений в соответствии с правилами именования в целевой СУБД;
  • Выяснить типы данных для атрибутов;
  • Сгенерировать SQL-код.

Теоретический материал:

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

В данном лабораторном практикуме в качестве целевой СУБД рассматривается MS SQL Server 2000. Соответственно, в данной и следующих лабораторных работах мы будем придерживаться принципов работы в данной СУБД.

Делая проектирование базы данных в среде ERWin, для перехода к физической модели требуется переключиться на физический уровень в раскрывающемся перечне (в том случае в случае если изначально была выбрано логико-физическое проектирование). ERWin машинально выполнит начальное преобразование логической модели в физическую. Разглядим, какие конкретно действия входят в это преобразование:

  • Переименование сущностей. В физической модели сущностям будут соответствовать таблицы базы данных. Создавая логическую модель, мы имели возможность давать сущностям каждые имена. Но на уровне физической модели, имена таблиц должны подчиняться правилам именования в целевой СУБД. В MS SQL Server 2000 имена таблиц смогут содержать буквы, цифры и знак подчеркивания, наряду с этим первым знаком должна быть буква. Буквы смогут быть как латинские, так и русские, но рекомендуется применять лишь латиницу. Эта совет связана с тем, что в некоторых случаях происходит некорректная обработка таблиц, имеющих имена, написанные русскими буквами.
  • Переименование атрибутов. На физическом уровне атрибутам соответствуют столбца таблицы. К именам столбцов в MS SQL Server 2000 используются те же правила, что и к именам таблиц (эти правила распространяются на все объекты MS SQL Server 2000).
  • Развязка связей типа «многие ко многим». В случае если в ходе логического проектирования кое-какие сущности были связаны между собой связью данного типа, ERWin машинально выполнит ее преобразование в идентифицирующие связи. Наряду с этим оба отношения, участвующие в связи «многие ко многим» будут выступать в роли родительских, а дочерним будет новое (машинально созданное) отношение, складывающееся из атрибутов, входящих в составы первичных ключей родительских взаимоотношений. Вторых атрибутов у него не будет. Такие отношения в теории баз разрешённых принято называть связными. Практически, на физическом уровне разглядываемые сущности будут связаны между собой не напрямую, а через машинально сгенерированное связное отношение.

Не считая указанных действий, ERWin кроме этого задаст для столбцов типы данных. Но это происходит по определенной в нем схеме соответствия типов данных доменам и не всегда оптимально. На практике в большинстве случаев требуется перепроверить схему разрешённых и задать типы данных самостоятельно. Не считая типов данных мы кроме этого можем задать ограничения. Разглядим, какие конкретно типы данных и ограничения возможно применять в MS SQL Server 2000.

Типы данных для хранения символьных строчков:

  • Char (n), где n – натуральное число. Хранит символьные строчки фиксированного размера (n знаков). В случае если знаков с сроке меньше n, к ней добавляются пробелы. Разрешает хранить до 8 кб текста;
  • Varchar (n) – употребляется для хранения строчков переменной длины, не более n знаков. Кроме этого разрешает хранить до 8 кб текста;
  • Text – употребляется для хранения громадных количеств текста;
  • nChar(n), nVarchar (n), nText – типы данных, предназначенные для хранения текста в формате Unicode (Прошлые типы хранили текст в формате ASCII)

Числовые типы данных:

  • tinyint – целые числа [0, 255]. Отводится 1 байт на хранение данных этого типа;
  • smallint – целые числа [-32768, 32767]. Отводится 2 байта;
  • int – целые числа [-2147483648, 2147483647]. Отводится 4 байта;
  • bigint – целые числа. Отводится 8 байт;
  • real – числа с плавающей запятой. [-3.4 E38, 3.4 E38];
  • float – числа с плавающей запятой [-1.79E308, 1.79 E308];
  • decimal (n,m) – числа с фиксированной запятой. n – количество цифр в числе, m – количество цифр по окончании запятой. Данный тип эквивалентен типу numeric из SQL-92;
  • smallmoney и money – эти типы употребляются для хранения финансовых сумм. Отличаются от decimal тем, что по окончании запятой возможно не более 4 цифр.

Типы даты и времени:

  • smallDateTime – хранит значения даты и времени. Возможно применять даты из промежутка 01.01.1990 – 06.06.2079. Занимает 4 байта;
  • DateTime — хранит значения даты и времени. Возможно применять даты из промежутка 01.01.1753 – 31.12.9999. Занимает 8 байт;

Другие типы данных:

  • Binary, varbinary, image – употребляются для хранения бинарных строчков. Модно совершить соответствие с char, varchar, text;
  • Uniqueidentifier – употребляется для хранения GUID (глобальных неповторимых идентификаторов). В базе разрешённых может быть лишь один столбец для того чтобы типа;
  • SQL-variant. Соответствует типу Variant в Visual Basic. Занимает 16 байт. Употребляется в тех случаях, в то время, когда появляется затруднения в выборе подходящего для столбца типа данных.

Типы разрешённых позволяют определить, какого именно рода информация будет храниться в столбце. Чтобы задать тип данных в ERWin, необходимо два раза щелкнуть мышкой по таблице. Откроется диалоговое окно, в котором мы можем выбирать столбцы данной таблицы и задавать для них разные параметры, среди них и типы данных. Не считая типа данных, для столбца возможно задать ограничения. В MS SQL Server 2000 ограничения являются механизмом , благодаря которому возможно осуществлять контроль значения хранящиеся полях строчков. Ограничения делятся на ограничения уровня уровня и ограничения столбцов таблицы. Разглядим их более детально:

Ограничения уровня столбцов – разрешают осуществлять контроль значения, хранящиеся в полях конкретного столбца.

  • NULL – разрешает хранение безлюдных (неизвестных) значений. К примеру, в столбце phone (телефон) не все поля возможно заполнить, т.к. не у всех имеется телефон;
  • NOT NULL – запрещает хранение неизвестных значений;
  • DEFAULT – разрешает задать значение по умолчанию. В случае если в поле не вводится никаких значений, то в него подставляется значение по умолчанию. К примеру: default 2 либо default ‘Office’;
  • UNIQUE – снабжает отсутствие повторяющихся значений в полях столбца;
  • PRIMARY KEY – определяет первичный ключ (на уровне столбцов употребляется при атомарного первичного ключа);
  • CHECK (logical_expression) – ограничение представляет собой логическое условие (logical_expression), при исполнении которого в поле дано вставлять значение. есть замечательным механизмом контроля значений хранящихся в полях. К примеру: check (age 18), check (status between 1 and 4).

Ограничения уровня таблицы – употребляются, в случае если нужно задать ограничение, распространяющееся на всю таблицу.

  • UNIQUE (column_list) – запрещает повтор значений в перечисленных столбцах (column_list). Употребляется в случаях в то время, когда нужно обеспечить уникальность не значений каждого столбца в отдельности, а совокупности хранящихся в ней значений. К примеру: unique (f_name, l_name) – снабжает уникальность имени и фамилии. Пара значений «Иван Петров» не должна повториться в таблице. Если бы мы задали это ограничение для каждого из указанных столбцов в отдельности (на уровне столбцов), то мы не имели возможность вводить такие пары значений как «Иван Сидоров» либо «Сергей Петров»;
  • PRIMARY KEY (column_list) – данное ограничение употребляется на уровне таблиц, если она имеет составной первичный ключ. Атрибуты, входящие в состав первичного ключа должны быть перечислены в column_list;
  • FORIGN KEY – разрешает выяснить внешний ключ. Атрибуты, являющиеся внешним ключом в одной таблице в обязательном порядке должны быть связаны с соответствующими им атрибутами, входящими в первичный ключ второй таблицы (правило ссылочной целостности). Главное слово REFERENCES разрешает указать, с какой таблицей устанавливается сообщение. В случае если столбцы входящие в первичный ключ данной таблицы имеют те же имена, что и столбцы внешнего ключа, то их показывать необязательно. В другом случае их показывают в скобках по окончании имени таблицы. Синтаксис ограничения имеет следующий вид:

FOREIGN KEY (список_столбцов) REFERENCES имя_таблицы (список_столбцов) команда

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

  • ON DELETE SET NULL – устанавливает в null связанные столбцы дочерней таблицы, при удаления соответствующих им значений из родительской таблицы;
  • ON DELETE CASCADE – разрешает каскадное удаление;
  • ON DELETE NO ACTION – не предпринимает никаких действий при удаления;
  • ON UPDATE CASCADE – разрешает каскадное обновление;
  • ON UPDATE NO ACTION — не предпринимает никаких действий при обновления.

Не считая работы с таблицами, процесс физического проектирования включает в себя разработку представлений, сценариев, хранимых триггеров и процедур. Все это возможно создать посредством ERWin, но направляться учитывать, что в нем возможно создавать лишь достаточно простые представления, а для хранимых триггеров и процедур он применяет личный язык программирования, хороший от T-SQL. По данной причине мы будем разглядывать разработку указанных объектов конкретно в среде MS SQL Server 2000. Конечный итог работы Erwin возможно представить в виде sql-кода, что он генерирует машинально (по команде schema generation из меню tools).

Вопросы к допуску

1. Какова цель физического проектирования базы данных?

2. Что такое «целевая СУБД»? Как в ERWin указать целевую СУБД?

3. Что входит в процесс физического проектирования базы данных?

4. Какие конкретно действия именуют начальным преобразованием логической модели в физическую?

5. Какие конкретно объекты создаются на этапе физического проектирования? Коротко охарактеризуйте их;

Контрольные вопросы

  1. Как перейти к физическому представлению модели в ERWin?
  2. Какие конкретно объекты возможно создавать в ERWin в физических моделях?
  3. Какие конкретно преобразования осуществляет ERWin при переходе от логической модели к физической?
  4. Как происходит развязка связей типа многие ко многим?
  5. Как указать необходимый тип столбца в среде Erwin?
  6. Какие конкретно типы данных употребляются в MS SQL Server 2000 для хранения числовых данных? Чем они различаются?
  7. Какие конкретно типы данных употребляются в MS SQL Server 2000 для хранения текстовых данных? В чем отличие между ними?
  8. Что именуют ограничением? Какие конкретно виды ограничений поддерживаются в MS SQL Server 2000?
  9. Перечислите и коротко охарактеризуйте ограничения уровня столбцов. В каких случаях они употребляются?
  10. Перечислите и коротко охарактеризуйте ограничения уровня таблицы. В каких случаях они употребляются?

Лабораторная работа №3:
«Создание таблиц базы данных в MS SQL Server 2000»

Задание:

  • Создать таблицы посредством T-SQL, применяя Query Analyzer;
  • Показать умение трудиться с таблицами в Query Analyzer – просмотр, удаление и редактирование таблиц посредством T-SQL;
  • Показать работу с таблицами в Enterprise Manager – создание, редактирование, просмотр.

Теоретический материал:

MS SQL Server 2000 является сервером баз данных промышленного уровня. Он предоставляет много разнообразных сервисов для работы с базами данных. Для работы с базами данных и их объектами в MS SQL Server 2000 в большинстве случаев применяют такие инструменты как Enterprise Manager и Query Analyzer. Enterprise Manager предоставляет возможность визуальной работы с базами данных и их объектами, и содержит в себе конструкторы и различные мастера. Query Analyzer является средой разработки кода программы на языке Transact SQL (в будущем — T-SQL).

Так, мы имеем возможность трудиться с объектами баз данных или применяя код T-SQL, или применяя мастера и конструкторы. В лабораторном практикуме нами будут рассматриваться и тот и второй методы.

Разглядим процесс работы с таблицами на языке T-SQL. направляться подчернуть, что, применяя CASE-средства проектирования, такие как ERWin мы можем сгенерировать в нем sql-код для таблиц по созданной схеме данных. Но далеко не всегда подобный инструментарий генерирует валидный и оптимальный код. Исходя из этого мы разглядим процесс создания таблиц на языке T-SQL сначала. При исполнении лабораторной работы, возможно не создавать таблицы заново, а отредактировать созданный в ERWin код программы.

Для новых объектов в языке T-SQL употребляется команда CREATE. Данная приказ может иметь различный синтаксис для различных объектов. Разглядим, как применять команду create для таблиц.

CREATE TABLE имя_таблицы

(

описание столбца1,

описание столбца2,

описание столбцаN,

описание ограничения уровня таблицы1,

описание ограничения уровня таблицыN

)

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

имя_столбца тип constraint имя_ограничения ограничение

его тип и Имя столбца в обязательном порядке включаются в описание. Ограничению может предшествовать главное слово CONSTRAINT и имя ограничения, но это не есть необходимым и помогает для вероятной предстоящей работы с данным ограничением (к примеру, удалять ограничения при редактировании таблицы командой alter table возможно лишь по их имени). Каждому столбцу возможно назначено произвольное количество ограничений уровня атрибутов, от нуля и более. Все ограничения кроме этого отделяются друг от друга пробелами. Показателем описания нового столбца (либо описания ограничений уровня таблицы) помогает запятая.

В T-SQL допускается применение вычисляемых столбцов в таблицах. В таких случаях синтаксис описания столбца выглядит следующим образом:

SQL таблицы. Ограничение столбца CHECK в базах данных SQLite. Правило CHECK в языке SQL.


Также читать:

Понравилась статья? Поделиться с друзьями: